SSL/TLS の暗号アルゴリズムの決定メカニズムをパケットレベルで追いかけてみる - /dev/null blog
楽しいことを見つけると寝食を忘れてのめり込んでしまう、プラットフォーム・グループの坂井です。 最近は SSL/TLS のプロトコルを調べるのが楽しくて、RFC のドキュメントや関連書籍を読み漁っています。 SSL/TLS で通信するためには、クライアントとサーバの両者でどの暗号アルゴリズムを使うか決めなくてはなりません。ブラウザの種類やバージョン、サーバの設定や実装など、様々な要素から暗号アルゴリズムは決定されます。 暗号アルゴリズムの決定メカニズム 暗号化通信が開始されるまでにはハンドシェイクプロトコルに則った処理が行われますが、暗号アルゴリズムの決定は最初の 1 ターン目で決まります。 クライアントが利用可能な暗号アルゴリズムの一覧を送信 (Client Hello) サーバは送られてきた一覧から使用するアルゴリズムを決定 (Server Hello) クライアントは自分が使える暗号ア
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
HTTPS通信時のURLは暗号化されるか - うまいぼうぶろぐ
2018/06 追記 古い記事ですがちょこちょこアクセスいただいているので更新。 最近は常時SSL、IPv4枯渇、CDN導入などの理由でSNIが良く使われるようになってきていますが この場合、ホスト名(URL全体ではない)は平文で送信されます。 client 側でキャプチャしたパケット curl -k https://sni.example.com/hogehoge $ sudo ngrep -d en3 -q -W byline port 443 and host 192.0.2.1 interface: en3 (192.168.6.0/255.255.255.0) filter: (ip or ip6) and ( port 443 and host 192.0.2.1 ) T 192.168.6.108:55460 -> 192.0.2.1:443 [AP] ...........
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
