DNSを使ってTLSハンドシェイクを高速化するZTLSについて - ASnoKaze blog
「ZTLS: A DNS-based Approach to Zero Round Trip Delay in TLS」という論文が公開されている。アイデアが面白いので簡単に眺める。 PDFも今のところACMのサイトから見れる https://dl.acm.org/doi/abs/10.1145/3543507.3583516 概要 DNSからTLSハンドシェイクに必要な情報を通知し、0-RTTハンドシェイクを行う 通常のTLSと互換性がある シーケンス図 (引用: 「ZTLS: A DNS-based Approach to Zero Round Trip Delay in TLS」 Figure 3) 事前に、サーバ側はZ-Data(ハンドシェイクに必要な情報)をDNSにアップロードしておく クライアントはサーバDNSに対してAレコードと、Z-Dataを含むレコードを並列に問い合わせ取
UTMの概要(ファイアウォールとの違い)と導入理由、おすすめメーカ、デメリットや必要無いという意見について | SEの道標
UTMとはファイアウォールはセキュリティのためのアプライアンス NW 機器ですが、できることはレイヤー 4 までの制御、つまり、送信元、宛先の IP アドレスや TCP/UDP のポート番号により、通信を制御することまでです。 しかし、昨今ではマルウェア対策を始め、様々なセキュリティ対応が求められるようになってきており、 そのセキュリティ対策 1 つ 1 つに設備投資するのは効率的ではありません。 そこで登場したのが UTM (Unified Threat Management) です。 UTM は従来のファイアウォール機能に加え、アンチウィルスや IPS、スパム、URL フィルタ等の様々なセキュリティ機能が搭載しており、ライセンスを追加することで必要な機能を必要なタイミングで適用することができるセキュリティ製品です。 UTM の役割、機能UTM の機能には、主に以下の4つがあります。 ア
Let’s write Swift code to intercept SSL Pinning HTTPS Requests
One of the popular ways to inspect HTTPS requests in iOS Apps is the Man-in-the-middle (MITM) attack. This technique requires a machine to be used as a proxy server for the client. For this to work, the client has to install the proxy server’s certificate into the device global trust store. By doing this, the client whitelists the certificate and hence allows HTTPS communication…
社内勉強会で専門的技術力を高めるには
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯（ヤフー内のスキル任命制度／ネットワーク・セキュリティ）に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
図解 X.509 証明書 - Qiita
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
TLS 1.3 開発日記 その16 Wireshark - あどけない話
Wiresharkはv2.3.0からTLS 1.3 draft 19に対応する。めでたい。すぐに使いたい人は、Nightlyビルドをとってくるとよい。 追記：v2.5.0rc0-1840-gd35ed012ce から TLS 1.3 draft 22 に対応している。(draft 22 はまだ出てないけど。) 使ってみる ポート13443で起動しているHaskellサーバとpicotlsクライアントの通信をtcpdumpでキャプチャしたファイルを"pico.pcap"とする。これを表示してみよう。 % tshark -dtcp.port==13443,ssl -Y ssl -r pico.pcap -V Secure Sockets Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handsh
WiresharkのTLS1.3対応 動いた - ASnoKaze blog
TLS1.3動いたシリーズの第3回目(?) WiresharkはTLSの実装一覧ページ(URL)では、以前よりTLS1.3対応をうたっていたがあまり出来は芳しくなかった。しかし、先日 TLS1.3絡みのコミットが幾つか入ったので、実際に改善されていることを確認した コミットログ(URL)を見る限りdecryptにも対応しているようなので、復号もできそうだが、TLS1.3になって復号に必要なパラメータが変わったため SSLKEYLOGFILEまわりの仕組みがどうなってるかはよくわからない。picotlsだと、うまくいくかもしれない(URL) 2019年5月追記: すでに復号対応しております。SSLKEYLOGFILEを食わせれば復号できる。 ビルド 今回は簡単に、CUI版であるTsharkをtrustyでビルドする sudo apt-get install -y flex libglib2.
TCP serverをSSL/TLS化するのに nginx の stream_ssl_module/stream_proxy_module が便利 - たごもりすメモ
最近 Fluentd の通信プロトコルまわりをアップデートするためにあれこれいじっている*1んだけど、これはおおむね fluent-plugin-secure-forward がサポートしていた内容を Fluentd 組込みの forward plugin でもサポートしますよ、というものになる。 んで問題なのが secure-forward は SSL/TLS での接続のみしかサポートしてなかったんだけど forward では生の TCP で通信する*2ので、本当に secure-forward と forward それぞれの実装間で互換性が保たれているのか、直接的には確認する手段がない、ということになってしまう。 TCP server の SSL/TLS 化 一方世の中には SSL/TLS ターミネータという機能があって、たとえばロードバランサなんかがこの機能を持っている。何をやるかと
HTTPSにまつわる怪しい伝説を検証する - Google I/O 2016のセッションから - Qiita
今年はGoogle I/Oに初めて社員ではない立場で参加しました。全体の感想は Google I/O 2016まとめ（Web的視点） で公開していますが、今回はその中で、気に入ったセッションの1つである"Mythbusting HTTPS: Squashing security’s urban legends"について書いてみたいと思います。 セッションは大変良くまとまっていますので、YouTubeにあがっている動画を見れる人は動画を見て貰えれば良いのですが、時間が無いという人のために、その内容をまとめました。基本的には文字起こしに近いものです。 重要だとわかっているけど、なかなか導入に踏み切れない人も多いHTTPS。これについて、最新の状況が理解できるコンテンツとしてお役に立てるならば嬉しいです。 TL;DR HTTPSはPWAppなどWebにとって必須。 しかし、パフォーマンス悪化する
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
Programming TCP for responsiveness
The document discusses optimizations to TCP and HTTP/2 to improve responsiveness on the web. It describes how TCP slow start works and the delays introduced in standard HTTP/2 usage from TCP/TLS handshakes. The author proposes adjusting the TCP send buffer polling threshold to allow switching between responses more quickly based on TCP congestion window state. Benchmark results show this can reduc
リモートのコンテナからDockerコマンドを使えるようにする - Qiita
ローカルのDocker EngineであればDockerのコントロール・ソケットdocker.sockをbindマウントするだけなので、下記のようにわりとシンプルなコマンドになります。 しかし、この方法だとリモートのDocker Machineにあるコンテナでは期待通りに動作してくれません。それではどうするかというと、Docker Machineとやり取りするための環境(pemファイルも含める)をコンテナに渡す必要があります。 例えば下記の手順をふむと、dockercontrolという名前のコンテナを作ってそのコンテナ上の/dockerというボリュームにその環境を保存することができます。 # 環境を設定します $ eval $(docker-machine env host1) # 環境を保存するためのコンテナを作ります $ tar -C $DOCKER_CERT_PATH -cf- ca
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【図解】https(SSL/TLS)の仕組みとシーケンス,パケット構造 〜暗号化の範囲, Encrypted Alert, ヘッダやレイヤについて～
GitHub - Shyp/generate-tls-cert: Generating self signed certificates
祝RFC！Transport Layer Security (TLS) 1.3 発行の軌跡 ～熟成された4年間の安全性解析～｜株式会社レピダム
kontena.io
TLS徹底演習
One container to rule them all
通信の安全を守るためにエンジニアができること
