逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
QUIC for SSH の提案仕様が出たよ - ASnoKaze blog
「QUIC-based UDP Transport for SSH」という提案が提出されています。 トランスポートプロトコルとしてQUICを利用することで、様々な恩恵を受けることが出来ます。 ユーザランドでコネクションが管理されるため、TCPとは異なりOSレイヤのでコネクション切断の影響をうけない IPアドレスが変わっても接続を維持できる(コネクションマイグレーション) 経路上の第三者による切断に耐性がある(QUICでは通信の切断にも鍵が必要) 個人的にも、SSHがQUIC上で動作することで切断しづらくなることを期待しております。 それでは、この仕様についてざっと見ていくことにしましょう。 ただ、まだまだこれから議論がされる提案仕様ですので、設計は大きく変わるでしょう。 QUIC-based UDP Transport for SSH の概要 QUICは内部的にTLSハンドシェイクを行って
QUICの仕様を翻訳していく (追記 2018/10/26 - ASnoKaze blog
2018/10/26 現在最新版の draft-16 について翻訳を開始しました GitHub - flano-yuki/my-quic-spec-translation: QUICの仕様の翻訳 2017年追記 2017年時点で、仕様は更新され、拡張仕様も出てきています。 asnokaze.hatenablog.com QUIC in ietf96 「Google の試験的トランスポート、QUIC のアップデート」などでも紹介されている、Googleが提案・実装してるQUIC。 すでに関連するドキュメントはChromium Projects配下のページで公開されていますが、先日IETFにQUICの仕様が提出されています。 さらに先週ドイツで行なわれたIETF96の中でQUICに関する議論が行なわれ、IETFとしてQUICの標準化を進める事が決まりました。セッションの発表ではQUICのプロト
WiresharkでHTTP/2をパケットキャプチャする - ASnoKaze blog
20190417追記 HTTP/3はこちら「WiresharkでのQUICの復号(decrypt) - ASnoKaze blog」 20151030追記 TLSを利用するHTTP/2では、秘密鍵を設定しても通信を復号することは出来ません。 HTTP/2の鍵交換はPFSなので、下記も参考にして下さい 「Wireshark で HTTP/2 over TLS の通信をダンプする方法」 https://gist.github.com/summerwind/a482dd1f8e9887d26199 この記事は HTTP2 Advent Calendar の 9 日目の投稿です。 初めましてゆきと申します。HTTP/2アドベントカレンダーにはガチ勢しかおらず戦々恐々としております。 アドベントカレンダーネタとしては、Push周りを書こうとしてたのですが先日Push周りの素晴らしい記事が投稿されてし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
