  |
はてなキーワード: アドレスとは
国立西洋美術館が日時指定のチケットをオンラインのみで発売してるっていうんで、チケットを取ってみた。
これがほんとに使いにくい。
購入にあたってこんなにイライラするwebサイト、はじめて見た。
致命的に使えないわけじゃなくて、購入までの各ステップでそれぞれちょっとずつイライラさせられる。
厳密には国立西洋美術館だけじゃなくて途中からはe+のサイトだけど、もうなんかセットで苛立つ。
西美サイトで｢オンラインチケットは以下の各方法で販売してるよ｣って書いてある割に、その各サイトへのリンクが見当たらなかったり。
日時指定で空いてる日時をクリックした後、さらにもう一度日時一覧がズラっと出てきたり。
購入に会員登録がいるのかよ、面倒くせー…と思って進もうとしたら、会員登録方法の説明ページに移動するだけで、登録には一度トップページに戻らないといけなかったり。
メールアドレスで仮登録して、メールに書いてあるアドレスに移動したら、そこからさらにSMS認証があったり。
購入できた！チケットをダウンロードしよう！と思ってダウンロードボタンを押したら、Google Playが開いて、まず別アプリをダウンロードするよう求められたり。
もうなんなんだこの、購入者の心を細かくイライラさせる使いにくさは。
クソofクソ。
元エントリーの人がどこまで理解しているか不明だけど、自分が初心者だったときこういう説明がほしかったという話をしてみる。
暗号方式、特に公開鍵暗号の理解が難しいのはいくつか理由がある。
②素朴な利用例が少なく応用的な利用がいくつもある
また、ざっくりした概念以上のものをきちんと理解しようと思うと
④何がどのくらい安全で何がどのくらい危険かセキュリティ的な概念の説明
ここでは自分的にこういう順番で概念を把握していったという流れを書いてみる。
まず、物理的な錠前や書留郵便をイメージするのはあきらめてほしい。
あくまでもデジタルデータを別のデジタルデータに変換して再び元に戻すためのものだ。
公開鍵暗号登場以前は、パスワードを使って変換（暗号化）して、同じパスワードを使って元に戻す（復号化）という共通鍵暗号の時代が長く続いた。
それが暗号化のパスワードと復号化のパスワードで異なるものを使うという技術だ。
・特殊な数学的アルゴリズムでパスワード１から、それと対になるパスワード２を生成する
・パスワード１で暗号化したものがパスワード２で復号できるだけでなく、その逆つまりパスワード２で暗号化したものがパスワード１で復号できる（※）
今はその数学的アルゴリズムまで理解する必要はない。ただそういうことが可能になったというだけでいい。
パスワード１（秘密鍵）を自分以外が見られないように保管して、パスワード２（公開鍵）を通信相手に渡せば暗号通信ができそうということは理解できると思う。
ちなみにこのパスワードの長さは、プログラムで生成した100桁以上の数字が使われることが多く、それを定型的な千文字程度のテキストにして使われるのが一般的。
ツールで生成すると千文字程度のテキストファイルが秘密鍵用と公開鍵用の2個できる。
これだけの桁数なので暗号化復号化の計算はそれなりに時間がかかる。（※）
（※） このあたりは一般的な公開鍵暗号というよりRSA公開鍵暗号特有の話も混ざってます。詳しくは専門書参照
次にこの発明を使ったらどういうことができるだろうか、応用できる先を考えてみよう。
誰でも最初に思いつく例だけどシンプルすぎて共通鍵と変わらなくありがたみがない。
(b)僕にメッセージを送るときは僕の公開鍵で暗号化してね（いわゆる公開鍵暗号）
メッセージの送信先を間違って別人に送ってしまっても他人は読めないし、経路のどこかで盗み見や内容の一部を改竄されたりすることがない。
メッセージに返信するときは今度は「僕」ではなく相手の公開鍵を使って暗号化する。
(c)本文を毎回全部暗号化すると時間がかかるから共通鍵を君の公開鍵で暗号化したものを送るね。それを君の秘密鍵で復号したら以降は高速な共通鍵暗号で通信しよう（鍵交換）
共通鍵暗号の高速性というメリットを利用できて、かつ生の共通鍵がネットに流れるリスクを排除した良いとこ取りの方式。
(d)暗号化しない本文と、本文から計算したハッシュ値を秘密鍵で暗号化したものを送るね。公開鍵で復号化したハッシュ値がそっちで計算したハッシュ値と同じなら本文は改竄されてないよ。
それからこの暗号化は僕しかできないから確かに僕から送られた文書、僕から送られた内容であると保証できるよ。（電子署名）
この「電子署名」の実現により、さらに次のような応用が可能になる。
(e)ログイン時に毎回パスワードを打つと見られたりして危険だからユーザ名等に署名したものを送るね。公開鍵で復号（検証）OKならログインさせて（公開鍵認証）
(f)僕は信頼できるよ。これがAさんの署名入りのお墨付き。検証してみて。
Aさんは信頼できるよ。これがBさんの署名入りのお墨付き。検証してみて。
Bさんは信頼できるよ。これが世界一信頼できる人の署名入りのお墨付き。検証してみて。
（サーバ証明書）
前項のようなやりとりはほとんどアプリが自動的にやってくれるので、コンピュータ技術者以外の人が公開鍵や秘密鍵を直接扱う機会は現状ほとんどないと思う。
ウェブブラウザのアドレス欄に鍵マークが表示されていたらそれは鍵交換やサーバ証明書技術が使われていて、鍵マークを右クリックすると証明書を表示できる。
メールアプリでも最近は自動的に鍵交換やサーバ証明書が使われている。
もしメールアプリにPGPの設定オプションがあればそこで公開鍵と秘密鍵を設定すると特定の相手と本格的な暗号化メールがやり取り可能になる。
サーバ操作するコンピュータ技術者だと公開鍵認証もよく使われていて、ツールで生成した公開鍵をサーバに登録してログインに利用してる。
下記の記事に10Gsで提供されたルータの情報が載ってなかったので利用中の自分が調べてみた。
https://qiita.com/notoken3331/items/ca228e2ac28ac7ea4879
| メーカー | Huawei |
| 製品型番 | HN8255Ws |
まず情報として、ONUに割り当てられたIPv6のプレフィックスは/56だった。
ルータ機能でのWAN側インターフェースではおそらくそれより細かく切ったプレフィックスでIPv6アドレスが割り当てられてるはずだが
HN8255Wsの管理画面では確認する方法がないように見受けられる。
セキュリティ関連の設定については、詳細設定 → セキュリティ設定 → DoS設定に下記のチェックボックスがありデフォルト全有効
SYNフラッド攻撃の防止:
LAND攻撃の防止:
Smurf攻撃の防止:
WinNuke攻撃の防止:
グローバル ー HN8255Ws（ONU兼ルータ） ー NetGear GS110MX ー PC(Windows10)
iphone X (au) Wifi無効設定で iNetToolsアプリにて疎通確認及びポートスキャン
ちなみにauのLTE契約のみでテザリングでPCをぶら下げる場合、PCにはIPv4プライベートアドレスと
IPv6リンクローカルアドレスしか振られないので、テザリングPC端末からIPv6疎通確認は実行不可。
LET NET for DATAを契約すればテザリングPC端末側にもIPv6グローバルIP振られるらしいんだが、
わざわざこのためだけに契約変更する気にはならんのでテザリングでの検証は却下。
そのため、iphoneのアプリで疎通確認可能なiNetToolsを疎通確認用プログラムとして選定。
iNetToolsというアプリだとポートスキャンの時にプロトコル指定が出来そうにないのでポート番号のみを指定した。
TCP、UDP両方チェックしているのか、どちらか片方しかチェックしていないのかは情報が見当たらなかった。
両方チェックして両方疎通した場合のみOpen判定なのか、どちらか片方でも開いていればOpen判定なのかも不明。
疎通確認端末のiphoneXがWifi経由でなく単独でIPv6のグローバルアドレスに疎通確認できる事の証明として
「www.google.co.jp」のIPv6アドレスに対してpingで疎通確認し、その後ポートスキャンで各ポートが開いているかどうかを見た。
確認項目とその結果は下記の通り。
| iphoneXからwww.google.co.jpのIPv6アドレスへのicmpv6疎通確認 | アプリで疎通OK |
| WinPC割当IPv6グローバルアドレスへのicmpv6疎通確認 | アプリで疎通NG |
| WinPC割当IPv6グローバルアドレスへのポートスキャン(53) | アプリでClose判定(Open欄に出てこない) |
| WinPC割当IPv6グローバルアドレスへのポートスキャン(80) | アプリでOpen判定 |
| WinPC割当IPv6グローバルアドレスへのポートスキャン(135) | アプリでClose判定(Open欄に出てこない) |
| WinPC割当IPv6グローバルアドレスへのポートスキャン(139) | アプリでClose判定(Open欄に出てこない) |
| WinPC割当IPv6グローバルアドレスへのポートスキャン(443) | アプリでOpen判定 |
| WinPC割当IPv6グローバルアドレスへのポートスキャン(445) | アプリでClose判定(Open欄に出てこない) |
ちなみにルータのWAN側インターフェースが握ってるIPv4アドレス宛にも同じポートのスキャンをしたが、同じように80と443がOpen判定だった。
昔フレッツ光回線使ってた時にポートスキャンテストとかしてなかったので他の光回線のポートスキャンの結果がどうなるかは知らない。
10Gsはそれなりにマシっぽいが、HTTP/HTTPSのポートが空いてるとすると、HTTP/HTTPSの改竄パケット受け取っただけで問題が発生する脆弱性が端末搭載OSに発覚した場合は危険かもしれない。
ただ、アプリ側のOpen判定が微妙なので誰かちゃんとIPv6環境から真っ当なポートスキャン試してみて。俺はこれ以上検証しない。
不思議だ。
なんか広告が多いなと思って、何個か「興味ない」ってチェックしたことくらいしか思い当たらない。
まあABP入れてるけど。
こんにちは、増田に書くのは初めてだけど誰にも言えない私の思い出を書いておこうと思って書きました。
高校3年生、お金が欲しくなって援助交際をした。近日中にお金が欲しいんだよねと、クラスの一番仲の良い友達に相談したら「いい掲示板があるよ」と、援助交際の掲示板を紹介された。「私もやったことあるよ」と言われて、それならいいかと軽い気持ちで、サブメアドを書き込むと、大量のメールが届いた。
「こんにちは〜^_^」
とりあえず全てに返信をするけど全員とメールが続くわけではないため、とりあえず会話を続けてふるいにかける。残ったのは３人。
そのうちの１人がアドレスの設定を「子安武人」にしていてなんか面白いからその人とセックスすることにした。(処女ではない)
上野のラブホでエッチするはずだったが、その人は勃たなかった。「おかしいな…緊張してるからかなははは」とか言って、結局ベッドに入りながら1時間半ぐらいおしゃべりしただけで３万円くれた。バイトもしていない高校生からしたら超大金。帰り道はカバンが盗まれたらどうしよう、財布落としたらどうしよう、援交が警察にバレたらどうしようとヒヤヒヤしながら帰った。
大学に入るまでは受験で忙しかったから援助交際はしなかった。都内のそこそこいい学校に行き、一人暮らしでお金が無くてまた援助交際した。
最初はパパ活のつもりで出会い系サイトに登録したけどエスカレートして結局色々やった。
手コキ(個室漫喫)
たくさんしたな、懐かしいな
フェラチオしてあげた後に、君どこの店？って聞かれたのは嬉しかった。
11:00~12:00 〇〇さん(1h) 手コキフェラチオ ＠個室漫喫 1万
12:00~13:00 ××さん(1h) 手コキフェラチオ ＠個室漫喫 1万
14:00~17:00 △△さん(3h) セックス @ラブホ 5万
18:00~18:30 ⬜︎⬜︎さん (30min) パンツ生脱ぎ手渡し ＠カラオケ 5千円
20:00~22:00 ◉◉さん (2h) セックス @ラブホ ３万
こんな景気の良い日は１日で10万5千円getしちゃったりしてね。もちろん終わったその日は精神的にも肉体的にもぐったりだけど。
リピートして会ってくれる人たくさんいたな。楽しかったしもう時間もまあまあ経ってるから、印象的なエピソードをまた気が向いた時に記録として書いていきたいと思う。
今は援助交際はしていない。援助交際の怖いところは辞め時がわからないところ。辞める直前までは、私はいつになったら辞めるんだろうと思いながらやっていたところはあった。結局彼氏にバレて、やめなよって諭してくれて辞めることができた。だから彼氏に真剣に諭された時は、あぁやっと辞めれるなと思っていた。その人とは別れちゃったけど。
援助交際はギャンブルと一緒なんだよね。ギャンブルやったことないけど。色々してあげた後、お金もらえる時が一番アドレナリン出る。しかも男たち(客とは言わない、店じゃないからね)はありがとう、楽しかったよとか、良かったよって言いながらお金を渡してくるから、なんてwin-winな人助けなんだろう！なんて思ってた。
実際やめてからの１年間はなんて自分は汚いんだろうと、過ちを犯してしまったことを悔やんだ。活動する地域は限定していたから、用事があって援交してた街に行く時は辛くなった。今になってやっと懐かしい思い出として思い出せるようになってきた。
援助交際をしていた時はスナックでも働いていて、今はスナックはやめてアイドルをしている。ひどいアイドルだと思う。過去は過去だからと納得はしているが、実際自分をこうやって客観視するとひどい、本当にひどいアイドルである。ファンの人ごめんなさい。
援助交際して、スナックで働いて、アイドルやって、私はおばさんになるまではずっとこの、女を売り誰かから搾取するような生き方をしていくんだろう。援助交際もスナックもアイドルも、誰かを元気付けて対価をもらい、相手を日常生活に送り出していくという形式がどれも共通して当てはまってしまうのが可笑しくて笑ってしまう。やっていることの本質は一緒。世間の印象が段階的に”最悪”から”マシ”になっているだけだよ。
あーあおもろい人生。
教育業界の話なんだけど、だいぶ前からオンライン担当だったのよ。本体の100分の1とかの規模。1人で始めてコツコツ増やしてやっと先生4人、無邪気に喜んでたのさ。そしたら自粛。谷みたいな暗い所に居たら出っ張ってる山削られてフラットに。てかピッチャーマウンド程度の山の上。お前ら何やってたんだよ。紙配って、喋って終わり。2階の印刷機の方が速い？4階のマイクは2個目使用してください、1個目ノイズ入ります？そういう細かいとこ、大事だけど、おいおい！おいおい！こっちからGmailアドレス付与したので、ログインお願いします、OneDriveにアクセスお願いします、classroomのスレッド、2要素ログイン、パスワード、なんなんだよ！！
す う ね ん ま え か ら お ね が い じ で 、 ば 、 ぶ 、 ぶ 、 ぶーーーーー！
助けられた。
変数はメモリ上の番地に付ける名前だから、＆masudaを呼べば処理系がmasudaに付けたアドレスにあるバイトから次のNULLまでのデータが返るし、*masudaに書けば先頭が前後にズレるし、*masudaをmain()のエントリポイントに書き換えてprintf(masuda)すれば例外が飛ぶだろ
あぁいや、元増田ではあるが、
関数ポインタと、関数アドレスの表記式を書き間違えたのは事実だ。そこは負けを認めよう。
が、結果論として、
関数ポインタも、関数アドレスも 実質一般論で言う変数とは言い難い、準固定値であるという主張に切り替える
特に関数アドレスは固定値である という言い方はそれなりに条件をつければ、多くの賛同を得ると思うが
いちおう頑張れば、コンパイラなどが固定値に変換できるよな？これ
「関数ポインタ」って初心者向けの説明で言う箱と中身のうちの箱だから、中身は変化する（違うものも入れられる）的な話でしょ？
オンラインで手続きが出来るようになるってのはいい事ではあるんだけど、
掲題の件はどうやっても解決は難しいよな。
SSLの証明書なんかも詳細の内容までいちいち確認してる人も少ないだろうし。
労働人口が減っていく中で業務効率化も遅々として進まない現状では
そこに付け込む犯罪者は今までより更に手軽かつ巧妙な犯行が可能になる。
URLはやっぱりアルファベットだけでよかったんじゃないかと常々思う。
自国の言語、例えば日本語アドレスの方が好ましいと思う人ってどのくらいいるんだろう？
デメリットの方が大きいように思うんだよなぁ。
掲題の通りなのだが、まず自分はネットワークエンジニアではない。この業界に関わって10年程のひよっこだ。
企画から開発、運用まで軽くではあるが1通りやったことがある。IPv6が使われているシステムの開発や構築、運用の経験はない。
知識はネットワークを勉強をして読んだ本にかかれてあることを勉強した程度（O'ReillyのIPv6アプリケーション適応ガイドとか読んだ記憶がある）。
ただ、毎回IPv6が書かれている章を読むたびに何故こんな設計にした？とモヤモヤする。
動かなくなるとか論理的な矛盾があるわけではないのだろうが、これは開発や運用を現場でやったことのないネットワークエンジニアが理想だけでつくりあげたものなのではと思ってしまう（ちなみに経緯を調べても既存のIPv6の仕組みが変わるわけではないので調べてません）。設定作業や障害対応を考えても人間が扱うには複雑すぎるような気がするというのが違和感のほとんどを占めるものだろう。
実際に運用するとなるとIPv6用の管理ツールをつくる必要がある気がするし、それを用意するためのお金や工数がもらえるところは（肌感覚でしかないが）少数派だと感じている。IPv6 を使っているところも足りなくなったIPv4のグローバルIPがわりに使われてシステム内部のプライベートのアドレスにあたるところはIPv4変換でこれまで通りというのがほとんどなのでは？と思ってしまう。
v6にかわるものが新しく出てほしい（出てこないだろうが）。そして実際にIPv6のみで設計、開発、運用されているシステムに携わっている人の意見が聞いてみたい。
というわけでその後の話し
Amazonカスタマーサポートの手によって不審なアカウントをロック状態にした旨のメールが送られてきた
お客様のAmazon.comアカウント上で、お客様ご自身が行っていない操作があることについて、お知らせいただき、ありがとうございました。 お客様の情報を保護するため、当サイト上からお客様のアカウントに登録されているクレジットカード情報にアクセスすることは不可能となっており、お客様のクレジットカード番号全桁がアカウントに表示されることもありません。
お客様のアカウントを再開するために、以下の措置を講じました。
●引用ここまで●
.comドメインなのが気になるところだけど、ひとまずアカウントロックと共にカード情報が削除されたこと、身に覚えのない注文は無効になったということで一安心
5時間後にアカウント再開ができるようになるらしいけど、カード情報が削除されているので勝手に注文して決済されることはない
氏名と住所、電話番号とかが丸見えのままなのかもしれないので、完全に解決したとはいえないかれしれないが
上記の措置から約20時間後に、Amazonからメールが届いた
要約するとアカウント情報の更新ができなかったからログインして確認しろという内容
文面は一見するとちゃんとしているが、そこはかとなくネイティブな日本人が書いたものとは違う不自然な臭いがする
更にメールに貼られたリンク先はAmazonを装った胡散臭いアドレスだった
恐らくアカウントロックされたので不正な手段で注文した奴らが再び誘導しようと試みたのではないだろうか
メールヘッダをざっくり読むと、SMTPサーバは[leemingglenn002.buzz]ということになっている
不正に注文されたのは4/18のことで、件のドメインは4/14に登録されていてまだ生きている(2020/5/9現在)
残念ながらｽｰﾊﾟｰﾊｯｶｰではないのでこれ以上のことはわからない
なお、正規のAmazonからのメール(アカウントをロックした旨を記載したメール)には「不正アクセスについてはAmazon側には責任がない(意訳)」「フィッシング詐欺に引っかかったか不注意にアカウント情報を漏らしたんじゃねーの?(意訳)」ということが書かれていた
