タグ

ブックマーク / asnokaze.hatenablog.com (9)

  • HTTP/3コネクション上でSSHを実行するSSH3プロトコル - ASnoKaze blog

    IETFに『Secure shell over HTTP/3 connections』という提案仕様が提出されています。 これは、HTTP/3コネクション上でSSHを実行するプロトコルを定義しています。なお、"SSH3"という名称を仕様中で使用していますが、あくまで提案段階ですので今後変わる可能性もあります。 SSH3ではHTTP/3を使うことにより以下の特徴を持ちます QUICのメリットが享受できる(例えばIPアドレスが変わってもコネクションを維持できる) HTTPの認証方式をサポートする(Basic認証、OAuth 2.0、Signature HTTP Authentication Scheme) SSH通信の秘匿 (第三者からするとただのHTTP通信にみえる) エンドポイントの秘匿 (Signature HTTP Authentication Schemeを使うことで、そこでサービス

    HTTP/3コネクション上でSSHを実行するSSH3プロトコル - ASnoKaze blog
  • 新しいステータスコード『420 Requester Impaired』の提案仕様 - ASnoKaze blog

    新しいHTTPステータスコード"420 Requester Impaired"を定義する『An HTTP Status Code to Report Requester Impairment』という提案仕様が提出されています。 これは、送信者の障害によりサーバは処理を拒否したことを示します。 目的として、重機などの機械やAIシステムが故障してることを示唆することを掲げています。提案仕様のなかでも次のように書かれています。 ある種のAIシステムは、与えられた入力に対して幻覚を見たり、不正確な答えを返したり、異なる答えを返したりといった行動を示すことがある。このようなAIが動作するスピードを考えると、人間の要求者と同様に、AIの要求者の障害を検出することも重要である。 (DeepL) 例 ステータスコードの定義なのでそのままなんですが、例としては次のとおりです (ボディは、RFC9457 形式

    新しいステータスコード『420 Requester Impaired』の提案仕様 - ASnoKaze blog
    defiant
    defiant 2023/12/18
    この記事をおすすめしました
  • 逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog

    『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse

    逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
    defiant
    defiant 2023/07/18
    この記事をおすすめしました
  • HTTP/3の解説を書いた (2020/06/01) - ASnoKaze blog

    @flano_yukiがHTTP/3について書きました。(無料です。 2020年6月時点の内容となっています。概ねQUICやHTTP/3の大枠は固まっており、2021年の内容と照らし合わせても、大きな変更はありません。PDFを下に貼ってあります。 , (宣伝) また、2021年6月にアップデートも含め、WEB+DB PRESS Vol.123に記事を書かせていただいております(有料) gihyo.jp http3-note https://github.com/flano-yuki/http3-notePDFを置きました 1. はじめに(HTTP/3と概要) 2. QUICについて 3. HTTP/3について 4. HTTP/3 拡張仕様と応用 5. (執筆予定) 実装、ツール紹介 公開形式は、そのうちなんとかするかも 内容 1. はじめに(HTTP/3と概要) 1.1 はじめのはじめ

    HTTP/3の解説を書いた (2020/06/01) - ASnoKaze blog
  • HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog

    この記事では、HTTP/3で導入されるHTTPヘッダ圧縮の仕組みである「QPACK 」について説明します。(執筆時 draft 07) 2020/06/01追記 まるっと解説記事を書き直しました asnokaze.hatenablog.com HTTP/2の場合 ハフマン符号 静的テーブル、動的テーブル HTTP/3とQPACKの導入背景 QPACKの概要 Encoder Instructions Decoder Instructions Header Block Instructions 相対インデックス Compressed Headers エラーハンドリング その他 QPACKという名称について HTTP/2の場合 簡単に、HTTP/2で導入されたヘッダ圧縮の仕組みである「RFC7541 HPACK」について補足します。飛ばしていただいても大丈夫です。 HTTP/2の元となったSPD

    HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog
  • HTTP over QUICと、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog

    [追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICのAckとロスリカバリについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze

    HTTP over QUICと、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog
  • NginxでTLS1.3の0-RTTハンドシェイク (ssl_early_data)を試す - ASnoKaze blog

    追記20180922 OpenSSLも対応しました 「support for TLSv1.3 early data with OpenSSL.」 http://hg.nginx.org/nginx/rev/548a63b354a2 昨日、NginxがTLS1.3の0-RTTハンドシェイクをサポートしたので試した。無事動作することが確認できた。 該当コミットはこの2つ SSL: enabled TLSv1.3 with BoringSSL. SSL: support for TLSv1.3 early data with BoringSSL. TLS1.3の0-RTTハンドシェイクは、一度ハンドシェイクをした相手とはClientHelloに続けてアプリケーションデータ(HTTPリクエスト)を送信することで、より早くデータのやりとりを開始する方法です。 (引用: https://blog.cl

    NginxでTLS1.3の0-RTTハンドシェイク (ssl_early_data)を試す - ASnoKaze blog
  • TLS over HTTPの提案仕様 - ASnoKaze blog

    TLS over HTTPである。HTTP over TLSではない。 「Application-Layer TLS」という提案仕様がCiscoの方より提出されている。(仕様中ではATLSと記述される) HTTP上でTLSレコードを送受信する仕様である。 TLSレイヤの実装変更はなくレコードをHTTPのボディで送受信できるようにする。なお、httpとhttps両方で使用可能である。 また、TLS1.2とTLS1.3などすべてのTLSバージョンに対応する。 来週からはじまるIETF100でも議論されるようなので、かいつまんで読んで見る。 クライアント クライアントからの基的なメッセージは、POSTでJSONを送信する。 Content-Typeにはapplication/atls+jsonを指定する POST /atls Content-Type: application/atls+jso

    TLS over HTTPの提案仕様 - ASnoKaze blog
  • googleの新しい時刻同期プロトコル Roughtimeとは - ASnoKaze blog

    [追記] 2020年1月時点の動向について、新しく記事を書きました asnokaze.hatenablog.com Googleの「Adam Langley氏のブログ」で、新しい時刻同期プロトコルについて紹介されている。このRoughtimeは特定のタイムサーバに依存しないセキュアな方法で時刻同期を行うことを目的としたプロトコルです。すでに、googleのサーバで動作しており、roughtime.sandbox.google.com:2002に向けて公開されている専用クライアントで接続できる。 現在のセキュリティは現在の時刻に依存しており、その重要性はましています。証明書の有効期限や、OCSPレスポンス、Kerberosのチケット、DNSSECの応用やPGP鍵といった機能でも重要です。しかし、Chromeの証明書エラーのうち25%はローカルの時刻に起因するとしているとしています。 現在、最

    googleの新しい時刻同期プロトコル Roughtimeとは - ASnoKaze blog
  • 1