HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 奥氏はHTTP/3に対応したHTTPサーバ「H2O」の開発を行うだけでなく、IETFでHTTP/3の標準策定にも関わるなど、日本においてもっともHTTP/3に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで
証明書300万件を強制失効。Let's Encrypt に一体何が起きたのか？ - Qiita
無料 SSL の認証局である Let's Encrypt は、有効な証明書のうち 2.6% に当たる300万件の証明書に対し、2020年3月4日に失効手続きを行うと宣言しました。しかもその事がユーザーに通知されたのは失効手続きの数時間前です。一体、Let's Encrypt に何が起きたのでしょうか？ 私が調べた事を共有したいと思います。 この記事は Let's Encrypt の証明書失効に関する一連の出来事についてまとめた物です。今回の失効処理の対象となっているかどうかの確認方法等については、以下の記事をご覧下さい。 Let's Encrypt に重大なバグが発覚。該当サイトは2020/3/4 までに対応が必須 更新しました(2020/3/7) 影響の度合いについての記載が正しくなかったので修正 現在の Let's Encrypt の見解が正しくなかったので修正 何が起きているのか？
Qualys SSL Labs - SSL Pulse
SSL Pulse is a continuous and global dashboard for monitoring the quality of SSL / TLS support over time across 150,000 SSL- and TLS-enabled websites, based on Alexa’s list of the most popular sites in the world. SSL Security Summary: This is the summary of the effective SSL security implemented by the most popular web sites. To be secure, a site has to be well configured, which means that it must
2つの公開鍵暗号(公開鍵暗号の基礎知識) - Qiita
はじめに TLS/SSLをはじめとして、様々な場面で公開鍵暗号が重要な役割を果たしているのは良く知られていることと思います。 ここで公開鍵暗号が何かというと、「かたやデータを公開鍵で暗号化して、かたや秘密鍵で復号する。他人にはデータの内容が漏れない」という説明が一般的です。 そうすると大抵の人は「TLS/SSL、公開鍵で暗号化して秘密鍵で復号するのね」と2つの情報を組み合わせ、それで納得してしまうわけですが、実は今日これは大体において誤り1です。 この誤りはいまやどうしようもなく広く流布していています。これは、適切な入門書がないことや、そもそも情報の検証を行う人が少ない ( そこまでする動機がない ) という理由によるわけですが、公開鍵暗号という言葉が2通りの意味で流通しているという面も大きいように思われます。 ということで、この2つの意味の違いに着目しつつ、基礎の整理を行いたいと思います
HTTP/1.x⇒HTTP/2 仕様変更で困ったこと (利用暗号の制約・httpヘッダーの小文字化) - Qiita
はじめに こちら、そろそろ知っておきたいHTTP/2の話という良くまとめられた記事を見ていて、色々と苦い記憶がよみがえってきたのですが、そういうHTTP/2仕様に困った系記事があまり見当たらなかったのでまとめました。 HTTP/2とは 機能 現在支流のHTTP 1/1よりもより効率よく、セキュアな通信をもらたす為に色々なアップグレードを施したHTTPの規格です。 特徴をざっというと、こんな感じ。 ストリーム、メッセージ、フレームという新しいデータの交換方式を利用することによる、実TCPセッション数削減 サーバー プッシュ機能により、複数のレスポンスが送信可能 HTTPヘッダーの仕組みを見直し、ヘッダー圧縮によるネットワーク負荷軽減 HTTPS(TLS)との関係 実はHTTP/2はHTTPSと深い関係があります。 実質的にHTTPS必須、しかもTLS1.2以上、cipher-suiteはTL
Let's encryptとSSL/TLSに関する誤謬 - Chienomi
全く以て意味不明な誤謬がはびこっていた上に、やたら上から目線だったので、消火しておこうと思う。 そもそもSSL, TLSとは何か SSL/TLSは暗号化技術である。 SSL/TLSのデータ通信自体は対称暗号である。ただし、暗号化に利用する暗号鍵は使い捨てる。 Cipherはかなり色々使えるのだけど、だいたいはTriple DES (3DES)かAESが使われる。 その手順は <- HelloRequest -> ClientHello <- ServerHello <- ServerCertificate <- ServerKeyExchange <- ServerHelloDone -> ClientKeyExchange -> Finished -> ChangeCipherSpec <- Finished <- ChangeChiperSpec <-> Application Dat
TLS実装の脆弱性「ROBOT」、19年前の攻撃が再来 大手各社の製品に影響
TLSの実装に関して1998年に発見された攻撃手法が、わずかに手を加えるだけで、現代のHTTPSに対して通用してしまうことが分かった。 インターネット上の通信暗号化に使われるTLSの実装に関して19年前に指摘されていた脆弱性が、主要メーカーの製品やサービスに存在していることが分かった。この問題を発見した研究チームは、当時「Bleichenbacher攻撃」と呼ばれた攻撃の再来として、「ROBOT（Return Of Bleichenbacher's Oracle Threat）」と命名している。 ドイツのルール大学ボーフムなどの研究チームは12月12日、この脆弱性に関する詳しい情報を公開した。それによると、1998年にダニエル・ブライヘンバッハ氏が、RSA暗号を使ったTLS通信の暗号化を破る攻撃手法を発見。研究チームは今回、この手法にわずかに手を加えるだけで、現代のインターネットを支えるH
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
Disclaimer 本エントリは、近々IETFで標準化される予定の新しいTLSの暗号方式 ChaCha20-Poly1305 について解説したものです。 本来なら、新しい暗号方式を紹介するいうことは、その暗号の安全性についてもちゃんと解説しないといけないかもしれません。しかし一般的に暗号の安全性評価はとても難しく、専門家でない者が暗号の安全性について軽々しく書くわけにはいかないなとも思いました。いろいろ悩みましたが、結局無用な誤解を避けるため、本エントリーでは ChaCha20-Poly1305 の安全性に関する記載を最小限に留めています。 今回紹介する ChaCha20-Poly1305 は、これまでも様々な暗号研究者の評価を受けている暗号方式ですが、まだNISTの標準や某国の推奨暗号リストに掲載されるといった、いわゆる特定機関のお墨付きをもった暗号方式ではありません。記載内容が中途半
ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS, Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
qpstudy 2015.11.14 一歩先を行くインフラエンジニアに知ってほしいSSL/TLS
インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;
Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
SSL/TLS 20年の歩みと動向～ - JPNIC
昨年2014年は、SSL（Secure Sockets Layer）とTLS（Transport Layer Security）というプロトコルがリリースされてから20年が経過し、HeartBleedやPOODLEなどの脆弱性でも話題となった年でもありました。今回の10分講座では、SSL/TLS暗号通信プロトコルの動向を紹介します。 SSL/TLSとは SSL/TLSは最も普及している暗号通信プロトコルの一つで、TCP/IPの4レイヤーモデルのトランスポート層とアプリケーション層との間に位置するため、広く使われているHTTPばかりでなく、SMTPなど任意のプロトコルを安全に送受信する目的で使用することができます。特にWebにおいて暗号通信機能を提供できるようになったことにより、オンラインショッピング、オンラインバンキングやユーザー認証を必要とする各種オンラインサービスの普及に重要な役割を担
Androidのバージョンと、SSL SNI(名前ベース)対応 - Qiita
意外と忘れがちなので。 Security with HTTPS and SSL https://developer.android.com/training/articles/security-ssl.html Common Problems with Hostname Verification ... Fortunately, HttpsURLConnection supports SNI since Android 2.3. Unfortunately, Apache HTTP Client does not 訳: HttpsURLConnectionを使っている場合は、Android 2.3以降でSNI(名前ベース)に対応しています。 ただし、アプリ(ブラウザなど)の対応状況や、必要な証明書が入っているかなどにも注意が必要です。 ブラウザはAndroid 3.0以降と書いてある所も
SSF - Secure Socket Funneling - Network tool - TCP and UDP port forwarding, SOCKS proxy, Remote shell, Native Relay protocol, Standalone
Secure Socket Funneling (SSF) is a network tool and toolkit. It provides simple and efficient ways to forward data from multiple sockets (TCP or UDP) through a single secure TLS link to a remote computer. The initial aim of SSF was to provide an easy way for users and developers to multiplex and demultiplex various network data flows. It was designed to: be cross platform (Windows XP-10, Linux, OS
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
細かすぎて伝わらないSSL/TLS
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの？」「いつ書くの？」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
libvirt: Description
Allow untrusted certificate for Https Connection Android