[B! TLS] wata88のブックマーク

逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog

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

wata88 2023/07/18

接続の更新周りで大変そうだけど良さそう

http
TLS

リンク

イラストで正しく理解するTLS 1.3の暗号技術

イラストで正しく理解するTLS 1.3の暗号技術初めにここではTLS 1.3︵以下TLSと略記︶で使われている暗号技術を解説します。主眼はTLSのプロトコルではなく、﹁暗号技術﹂の用語の挙動︵何を入力して何を出力するのか︶と目的の理解です。実際にどのような方式なのかといった、より詳しい説明は拙著﹃図解即戦力暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書﹄︵暗認本︶や﹃暗認本﹄の内容を紹介したスライドや動画などの資料集をごらんください。なお表題の﹁イラストで﹂は数式を使わないという程度の意味です。 TLSで守りたいもの TLSはコンピュータ同士が安全に通信するための規格です。主に人がブラウザを介して﹁https://﹂で始まるWebサイトにアクセスするときに利用されます。安全に通信するためには、通信内容が盗聴されても情報が漏れない機密性が必要です。それから通信が改

wata88 2022/03/15

TLS

リンク

あなたの「公開鍵暗号」はPKE? それともPKC? - Cybozu Inside Out | サイボウズエンジニアのブログ

初めにサイボウズ・ラボの光成です。いきなりですがクイズです。次のうち正しい説明はどれでしょう。 SSHやFIDO2などの公開鍵認証はチャレンジを秘密鍵で暗号化し、公開鍵で復号して認証する。ビットコインでは相手の公開鍵を用いてハッシュ値を暗号化して相手に送る。 TLS1.3ではサーバ公開鍵を用いてAESの秘密鍵を暗号化する。答えはどれも間違いです。公開鍵認証は、(デジタル)署名を使って相手先の正しさを検証するものであり、暗号化は行われません。同様にビットコインもデータや相手の正当性を確認するために署名が用いられ、暗号化は行われません。 TLS 1.3ではRSA暗号の公開鍵を用いて暗号化する方式(static RSA)は廃止され、ECDH鍵共有された値を元に秘密鍵を生成し、AES-GCMなどの認証つき暗号で暗号化します。公開鍵暗号とはいわゆる公開鍵暗号には大きく2種類の意味があ

wata88 2022/03/15

TLS

リンク

Let's Encryptの証明書切替周りその後 | おそらくはそれさえも平凡な日々

「Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。何もせずとも来年の1月11日までは猶予が伸びた証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいましたデフォルトRoot証

wata88 2020/09/23

Androidのライフサイクルよくわかんないけど、4年前のOSは古いっちゃ古いのか

TLS

リンク

Measuring and examining TLS 1.3, IPv4, and IPv6 performance - Matt Hobbs

First published: Jul 30, 2020 Last updated: Aug 5, 2020 Tagged: webperf, gds, ramblings. Matt Hobbs Read time: 21 mins Earlier in the year we enabled Transport Layer Security (TLS) 1.3 on the Fastly point of presence (POPs) for GOV.UK. Fastly have been gradually rolling out a whole set of improvements to the cache nodes in their POPs. This includes a new h2o TLS architecture, which was required fo

wata88 2020/08/11

リンク

求む！TLS1.3の再接続を完全に理解した方(Challenge CVE-2020-13777) - ぼちぼち日記

1. GnuTLSの深刻な脆弱性(CVE-2020-13777) 先日、GnuTLSで深刻な脆弱性が見つかりました。 GNUTLS-SA-2020-06-03: CVE-2020-13777 It was found that GnuTLS 3.6.4 introduced a regression in the TLS protocol implementation. This caused the TLS server to not securely construct a session ticket encryption key considering the application supplied secret, allowing a MitM attacker to bypass authentication in TLS 1.3 and recover previous c

wata88 2020/06/13

面白そう

TLS
security

リンク

Envoy threading model

Low level technical documentation on the Envoy codebase is currently fairly sparse. To rectify that I’m planning on doing a series of blog posts about various subsystems. As this is the first post, please let me know what you think and what other topics you would like to see covered. One of the most common technical questions I get about Envoy is a request for a low level description of the thread

wata88 2019/12/23

TLS
envoy

リンク

Fake SNIという提案仕様について - ASnoKaze blog

SNIを用いた通信のブロッキング及び、﹁Encrypted SNI拡張﹂のブロッキングについてはIETFのTLS WGでも話題となりました︵(TLS) SK filtering on SNI, blocking ESNI︶。 Encrypted SNIはSNIを暗号化する一方で、ClientHelloにencrypted_server_name拡張をつけます。そのため、経路上の観測者はEncrypted SNIが使われていることを検知できます。それを回避するために、ニセのSNIをつける﹁Fake Server Name Indication﹂というdraftが提出されています。初版のdraftであり、これから議論のあるところだとは思うが、とりあえず面白そうなので読んでみる。 Fake SNI Fake SNIを利用するサービスは事前に、偽のホスト名を公表します。DNSを利用することを想

wata88 2019/02/20

DNS
TLS

リンク

政府によるインターネットの検閲とSNIについて

しかし今回一般の人の目にも触れる形でSNIやHTTPSのことが報じられた結果、エンジニアも含めて明らかに技術に関して勘違いをしているのではないかと感じる発言を見ることがありました。このまま放置するのも良くないと感じているので、Q&Aという形でSNIやHTTPSに関する誤解を少しでも解ければと思います。 Q&AQ: そもそもSNIって何？以前書いた記事にも書かれているので是非読んでみてください。簡単に説明すると、HTTPSではSSL/TLSを利用して通信が暗号化されます。なので1つのIPアドレスで複数の証明書を扱おうとした場合、最初の通信時にどの証明書を利用すればいいか分かりません。そこでSNIが必要になります。 SNIは最初の通信時に今から通信したいサーバーネーム︵ドメイン名と考えてください︶をサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。SNIは現在の一般的なブラウ

wata88 2019/02/18

DNS
TLS

リンク

DNS over HTTPSの必要性について - Qiita

なぜ今までのDNSでは問題があるのかインターネット上の通信の多くは、ブラウザを利用したウェブによるものです。セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは今までDNSサーバ︵フルリゾルバ︶の︵主に︶UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ

wata88 2019/02/13

DNS
TLS

リンク

HTTP3Study に行ってきたメモ #http3study - console.lealog();

HTTP3Study (new) - connpass まったく詳しくない分野で脳内補完が効かないのと英語なのとで、まったく自信のないメモに仕上がりました。間違ってたらむしろ教えてほしいです！ HTTP/3 (英語セッション) from Mark Nottingham はじめにここは最初にWGのMtgをした部屋なので不思議な感じ仕様の解説というより、経緯とか周辺について話すよ仕様について議論してるけど、全ての実装・ユースケースを把握してるわけではないいままで HTTP/0.9 今でも使われてるかも `GET /`だけみたいにシンプル HTTP/1.0 いくつかヘッダがついたりしたまだシンプルだったあの頃 1993年とかそのへんからユースケースが混んできたなのでみんな拡張をはじめた UAとかHostとか HTTP/1.1 Transfer-Encoding: chunk gzi

wata88 2019/01/30

http
TLS

リンク

次世代Webカンファレンス 2019：HTTPSセッションが面白かった - ろば電子が詰まつてゐる

以前から気になっていた﹁次世代 Web カンファレンス 2019﹂を、ようやく聴きに行くことができました。たくさんのトークがありましたが、ここではHTTPS (hashtag: #nwc_https)をメモしておきます。なお、このセッションが間違いなく一番アツく、一番面白かったです!当日の動画 https://www.youtube.com/watch?v=_8dCa8wj8QY togetter https://togetter.com/li/1268794 以下、当日参加した、もしくは動画を見たという前提でのメモなので、見てない人はぜひ見ましょう。 PKI ﹁低レイヤから行きましょう﹂ということで、はじめはPKI絡み。Symantecのdistrustと、日本のGPKIの話でした。トーク中に何度か出てきましたが、認証局(厳密にはCAとRAを分けて書くべきですが、どうせみんな一緒な

wata88 2019/01/15

良いまとめ

https
TLS

リンク

QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog

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

wata88 2018/11/01

http
TLS

リンク

drwetter/testssl.sh: Testing TLS/SSL encryption anywhere on any port

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

wata88 2018/08/06

ssl
TLS

リンク

SSL/TLSについてまとめ2018 - Qiita

はじめに SSL/TLSについて改めて理解を深めたい思い、関連する技術についてまとめました。本記事はTLSに関すること主題として、HTTPS、暗号化、Apache、OpenSSL等について記載しています。 SSL/TLSの通信は色々なプロトコルや暗号化方式が組み合わされ補いあってできています。暗号化の仕組みはパズルのようで面白いです。一つ一つを読み取り理解が深まるごとで、SSL/TLSって本当によくできると思いました。フレームワークの意味について考えさられます。 HTTPSの通信 HTTPSの通信はTCP/IPプロトコルスイートとして、TCPの上層にSSL/TLSがあり、アプリケーションプロトコルのHTTPプロトコルが載って通信をしています。コネクションとセッションは通信の概念として別になります。TCPでクライアントからWebサーバに対してコネクション(経路)が確立され、その上でセッシ

wata88 2018/03/11

tls
security

リンク

大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b

↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。︻訂正事項︼スライド16: 誤‥たった一つのプロセスが故障しただけでも有限時間で合意できない正‥たった一つのプロセスが故障しうるだけでも有限時間で合意できないスライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら

wata88 2017/09/25

すごい頑張ってるすごい

tls

リンク

SSL/TLSサーバ証明書、コードサイニング証明書 | 国内最安値DigiCert（デジサート）正規代理店

世界最大のサイバーセキュリティ企業であるSymantec（以下シマンテック）と、暗号化ソリューションの大手プロバイダであるDigiCert Inc.は2017年8月2日（現地時間）、DigiCertがシマンテックのウェブサイトセキュリティ事業及びそれに関連するPKIソリューションを取得する契約の合意を発表しました。 DigiCert（デジサート）は、拡張性の高いソリューション、業界をリードする顧客サポートの提供や、業界のベストプラクティスの向上に重要な貢献をすることで、高い評価と高い顧客ロイヤリティを誇っています。シマンテックのウェブサイトセキュリティ事業及び関連するPKIソリューションを製品に追加することで、DigiCertは次世代のグローバルウェブサイトセキュリティをリードする驚異的な才能と経験を手にし、IoTの成長機会を活用してSSL市場に新しいアプローチをもたらす能力を得るでしょ

wata88 2017/08/03

ふあああああ

ssl
tls

リンク

httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita

課題サイトをを立ち上げるときに当然のごとくSSL証明書をベンダーから購入して設置していたが、いざセキュリティ診断等でチェックしてもらうとSSLについての指摘を何件か受けてみた。なんでだろうと思いながらも、さらに最適なSSL設定は？と聞かれてそういえばあまり昔から手を入れたことなかったなと思い調べてみた SSL通信が確立するまでの概要フロー SSL通信について再度おさらい Nginxを元にしたSSLの設定 nginxのHTTPS サーバの設定を参考に、たった2行だけどSSLを考えてみる。書き方は違えどもapacheも概念は一緒のはず。

wata88 2016/09/06

リンク

HTTP/2とTLSの間でapacheがハマった脆弱性(CVE-2016-4979) - ぼちぼち日記

0. 短いまとめ昨晩apache2.4でHTTP/2利用時にTLSクライアント認証をバイパスする脆弱性(CVE-2016-4979)が公表され、対策版がリリースされました。実際に試すと Firefoxで認証バイパスができることが確認できました。 HTTP/2でTLSのクライアント認証を利用するには仕様上大きな制限があり、SPDY時代から長年の課題となっています。この課題を解決するため、Secondary Certificate Authentication in HTTP/2という拡張仕様が現在IETFで議論中です。 1. はじめにちょうど昨晩、apache2.4のhttpdサーバの脆弱性(CVE-2016-4979)が公開され、セキュリティリリースが行われました。 CVE-2016-4979: X509 Client certificate based authenticatio

wata88 2016/07/08

多重化するからかぁ

リンク

新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記

Disclaimer 本エントリは、近々IETFで標準化される予定の新しいTLSの暗号方式 ChaCha20-Poly1305 について解説したものです。本来なら、新しい暗号方式を紹介するいうことは、その暗号の安全性についてもちゃんと解説しないといけないかもしれません。しかし一般的に暗号の安全性評価はとても難しく、専門家でない者が暗号の安全性について軽々しく書くわけにはいかないなとも思いました。いろいろ悩みましたが、結局無用な誤解を避けるため、本エントリーでは ChaCha20-Poly1305 の安全性に関する記載を最小限に留めています。今回紹介する ChaCha20-Poly1305 は、これまでも様々な暗号研究者の評価を受けている暗号方式ですが、まだNISTの標準や某国の推奨暗号リストに掲載されるといった、いわゆる特定機関のお墨付きをもった暗号方式ではありません。記載内容が中途半

wata88 2016/04/05

リンク

はてなブックマーク

タグ

関連タグで絞り込む (14)

TLSに関するwata88のブックマーク (22)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

今週のはてなブックマーク数ランキング（2024年7月第1週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス