Linuxのkernel TLSでnginxのSSL_sendfileを試してみた · hnakamur's blog
2021-10-31 はじめに OpenSSLのSSL_sendfileとパッチを当てたnginxでLinuxのkTLSを試してみた · hnakamur’s blog を書いてから1年半経って状況が変わっていたので再度試してみました。 9日前に SSL: SSL_sendfile() support with kernel TLS. · nginx/nginx@1fc61b7 で Linux の kernel TLS を使って sendfile するコードが nginx に入っていました。 コミットメッセージによると enable-tls オプションを有効にした OpenSSL 3.0 が必要とのことです。 検証環境 $ cat /etc/os-release | grep ^VERSION= VERSION="20.04.3 LTS (Focal Fossa)" $ uname -r
Let's EncryptのDST Root X3ルート証明書の期限切れとOpenSSLの影響についていろいろ試してみた
Let's Encryptでこれまで長く使用されてきたIdentrust社発行のDST Root X3ルート証明書が、日本時間2021年9月30日23時1分15秒に期限切れになりました。十分時間を取って事前に移行計画や影響範囲、救える環境、救えない環境などアナウンスをしてきましたが、やはり、期限切れ以降、様々なサービスや製品で接続できないといった声が上がってきました。 特にOpenSSLに関しては、OpenSSL 1.0.2以前に影響があると9月13日に事前の注意喚起がOpenSSL公式ブログであったにもかかわらず、製品やサービスの奥底で使われていて気づかなかったのか、様々なOSや製品で古いものが組み込みで使われていたために影響が広かったように思います。 OpenSSLからの注意喚起の概要 2021年9月30日にLet's EncryptのDST Root X3ルート証明書の期限が切れるに
Old Let's Encrypt root certificate expiration and OpenSSL 1.0.2
Old Let's Encrypt root certificate expiration and OpenSSL 1.0.2 Sep 13, 2021 The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates is
OpenSSL version 3.0.0 published
OpenSSL openssl at openssl.org Tue Sep 7 12:04:20 UTC 2021 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 3.0.0 released ============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 3.0.0 of our open source t
「RFC7525: TLSを安全に使うための推奨事項」の改定 - ASnoKaze blog
様々な組織や団体がTLSを安全に利用するためのドキュメントを出してたりする。 IETFでも2015年にRFC7525 「Recommendations for Secure Use of TLS and DTLS」として、使用する上での推奨事項をまとめている。 それについての詳細は、urushima先生の記事を見ていただくと良いと思う。 blog.livedoor.jp 上記のRFC7525から5年が経ち、その間にRFC 8446 TLS1.3の発行などもありました。そのため、IETFではこのRFC7525の改定作業が開始されました RFC7525bis IETFのUTA (Using TLS in Applications) WGでは、RFC7525の改訂版として、次のドキュメントをすでにWG Itemとして扱っている draft-ietf-uta-rfc7525bis ここでは、簡単に
Investigating TLS blocking in India
Simone Basso (OONI), Gurshabad Grover and Kushagra Singh (Centre for Internet and Society, India) 2020-07-08 This report investigates Transport Layer Security (TLS)-based blocking in India. Previous research by the Centre for Internet & Society, India (CIS) has already exposed TLS blocking based on the value of the SNI field. OONI has also implemented and started testing SNI-based TLS blocking mea
中国がTLS 1.3とESNIを使用するHTTPSトラフィックをブロック
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 中国政府は、国内の通信を検閲するシステムである「グレートファイアウォール」（GFW）をアップデートし、通信のインターセプト（傍受、妨害）を防止する最新のセキュリティプロトコルを使ったHTTPS接続をブロックし始めた。 中国の検閲状況を調査している3つの組織（iYouPort、メリーランド大学、Great Firewall Report）が米国時間8月7日に発表した共同レポートによれば、この状況は7月末から始まっているという。 中国政府はHTTPS＋TLS 1.3＋ESNIの接続をブロック GFWのアップデートで新たに標的になったのは、「TLS 1.3」や「ESNI」（Encrypted Server Name Indication）など
SSLサーバ証明書の有効期間を短縮するという決定に関する続報
2020年2月にApple社が「2020年9月1日以降に発行されるSSLサーバ証明書で、有効期間が398日を超える証明書をSafariでは無効とする」という発表を、グローバルサインブログで紹介しました。本日はその続報を紹介します。 その後、ブラウザベンダーのアナウンス CA/Browser Forumでは、SSLサーバ証明書の有効期間を398日未満とする、基本ルール(Baseline Requirements)を盛り込むよう、投票に向けた議論を重ねている最中ですが、2020年6月23日にオンライン会合の場で、GoogleやMozillaも相次いでAppleのアナウンスに同意するかたちで、9月1日以降に発行されるSSLサーバ証明書で、398日を超える証明書は無効化することをアナウンスしました。 これは、CA/Browser ForumのBaseline Requirementsの要件にかかわ
HTTPと硬直化 (ossification) の問題 - ASnoKaze blog
「硬直化(ossification)」はあまり聞き慣れない言葉だが、インターネットやWebの通信において問題となってきています。 新しい機能の展開を阻害するこの問題は、HTTPにおけても問題になっておりましたが、HTTPの標準化を行うIETFで動きがありました。 IETFのHTTP WGではオープンレターとして「HTTP and Web Application Firewalls: Managing Ossification Risk」を公開し、WAFベンダと連携してこの問題に取り組んでいく意思が示されています。 この事に関して簡単に説明していきます 目次 硬直化(ossification) とは HTTPにおける 硬直化(ossification) グリス (GREASE)の例 HTTPにおけるGREASE 硬直化(ossification) とは 「硬直化(ossification)」
図解 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. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
QUICむけにAES-GCM実装を最適化した話 (1/2)
4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
先週スウェーデンのKistaで開催された第５回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通
「SSL/TLS暗号設定ガイドライン 第2.0版」を読んで - ぼちぼち日記
1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 本文冒頭では、 「本ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性（相互接続性）のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと
Introducing managed SSL for Google App Engine | Google Cloud Blog
We’re excited to announce the beta release of managed SSL certificates at no charge for applications built on Google App Engine. This service automatically encrypts server-to-client communication — an essential part of safeguarding sensitive information over the web. Manually managing SSL certificates to ensure a secure connection is a time consuming process, and GCP makes it easy for customers b
一部の大手サイトでTLS 1.0無効化が始まる | スラド セキュリティ
TLS 1.0の無効化は2015年頃から叫ばれていたものの、様々な問題があり延期するサイトが多かった。しかし、とうとうTLS 1.0を無効にする大手サイトが出てくるようだ。 So-netは5月2日以降、一部サービスでTLS 1.0を無効化する。国税庁も5月13日以降、運営するサイトの多くでTLS 1.0を無効化するとのこと 。本番組織でのTLS 1.0無効化を延期していたSalesforceも7月23日に無効化を実施する。 なお、NTT Comは4月に予定していたBizストレージ ファイルシェアでのTLS 1.0の無効化を延期している。TLS 1.0の無効化は混乱なく進むだろうか。
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
錆びついたTLSを滑らかに、GoogleによるGREASE試験 - ぼちぼち日記
0. 短いまとめ 長い間、TLSのクライアント・サーバ間で使用するTLSバージョンを合意する際に、 不完全なサーバ実装によって version intolerance が発生することが問題になっていました。 TLS1.3ではこの version intolerance の影響を最小化するため、新しい version negotiation の仕組みを取り入れました。 Googleは、GREASE(Generate Random Extensions And Sustain Extensibility)という仕様をChromeに実装し、TLSサーバのバグで通らない拡張やフィールド値で問題が発生しないか試験を始めました。 パケットキャプチャが好きな人は、Chromeが 0x[0-f]a0x[0-f]a の見慣れない値をCipherSuiteやTLS拡張に使っているのを見つけても驚かないよう気を
Google’s QUIC protocol: moving the web from TCP to UDP
Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached. We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today! The QUIC protocol (Quick UDP Internet
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Go 1.16.6」「Go 1.15.14」が公開 ～1件の脆弱性を修正／crypto/tlsに不正な証明書でクライアントがパニックに陥る問題
Mozilla SSL Configuration Generator