A Rust-based TLS library outperformed OpenSSL in almost every category
A tiny and relatively unknown TLS library written in Rust, an up-and-coming programming language, outperformed the industry-standard OpenSSL in almost every major category. The findings are the result of a recent four-part series of benchmarks [1, 2, 3, 4] carried out by Joseph Birr-Pixton, the developer behind the Rustls library. Benchmark resultsThe findings showed that Rustls was 10% faster whe
政府によるインターネットの検閲とSNIについて
しかし今回一般の人の目にも触れる形でSNIやHTTPSのことが報じられた結果、エンジニアも含めて明らかに技術に関して勘違いをしているのではないかと感じる発言を見ることがありました。このまま放置するのも良くないと感じているので、Q&Aという形でSNIやHTTPSに関する誤解を少しでも解ければと思います。 Q&AQ: そもそもSNIって何？以前書いた記事にも書かれているので是非読んでみてください。 簡単に説明すると、HTTPSではSSL/TLSを利用して通信が暗号化されます。なので1つのIPアドレスで複数の証明書を扱おうとした場合、最初の通信時にどの証明書を利用すればいいか分かりません。そこでSNIが必要になります。 SNIは最初の通信時に今から通信したいサーバーネーム（ドメイン名と考えてください）をサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。SNIは現在の一般的なブラウ
Extended Validation is Broken
Extended Validation Is Broken By @iangcarroll Extended validation ("EV") certificates are a unique type of certificate issued by certificate authorities after more extensive validation of the entity requesting the certificate. In exchange for this more rigorous vetting, browsers show a special indicator like a green bar containing the company name, or in the case of Safari completely replace the U
How I tricked Symantec with a Fake Private Key - Hanno's blog
Lately, some attention was drawn to a widespread problem with TLS certificates. Many people are accidentally publishing their private keys. Sometimes they are released as part of applications, in Github repositories or with common filenames on web servers. If a private key is compromised, a certificate authority is obliged to revoke it. The Baseline Requirements – a set of rules that browsers and
HTTPS Certificate Revocation is broken, and it’s time for some new tools
This article was originally published on Scott Helme's blog and is reprinted here with his permission. We have a little problem on the web right now and I can only see it becoming a larger concern as time goes by: more and more sites are obtaining certificates, vitally important documents needed to deploy HTTPS, but we have no way of protecting ourselves when things go wrong. Certificates We're cu
Padding oracles and the decline of CBC-mode cipher suites
At CloudFlare, we’re committed to making sure the encrypted web is available to everyone, even those with older browsers. At the same time, we want to make sure that as many people as possible are using the most modern and secure encryption available to them. Improving the cryptography used by the majority requires a coordinated effort between the organizations building web browsers and API client
OpenSSLの脆弱性(CVE-2017-3733)に見られる仕様とcastの落とし穴 - ぼちぼち日記
0. 短いまとめ OpenSSL-1.1.0dに脆弱性(CVE-2017-3733)が見つかり、Encrypt-Then-Mac と renegotiation を組み合わせて crashさせることができました。 この脆弱性は、仕様の準拠不足や不適切な変数の cast などが原因でした。 TLS1.3ではこういう落とし穴が少なくなるよう機能の根本的な見直しが行われています。 1. はじめに 先週 OpenSSL-1.1.0d に対してセキュリティアップデートがあり、 Encrypt-Then-Mac renegotiation crash (CVE-2017-3733)という脆弱性(Severity: High)が公開されました。 対象となった 1.1.0 は、昨年2016年8月にリリースされたOpenSSLの新しいリリースブランチです。1.1.0ではAPIの大幅変更もあり、まだあまり普及
Building Zero protocol for fast, secure mobile connections
Building Zero protocol for fast, secure mobile connections Every day, more than a billion people use Facebook on Android and iOS devices to connect with their friends. Securing data in transit between our mobile apps and our servers helps ensure that people have a safe experience on Facebook. Our mobile apps use a custom networking stack called Mobile Proxygen, a C++14 cross-platform HTTP client w
So you want to expose Go on the Internet
Back when crypto/tls was slow and net/http young, the general wisdom was to always put Go servers behind a reverse proxy like NGINX. That’s not necessary anymore! At Cloudflare we recently experimented with exposing pure Go services to the hostile wide area network. With the Go 1.8 release, net/http and crypto/tls proved to be stable, performant and flexible. However, the defaults are tuned for lo
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 をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
錆びついた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拡張に使っているのを見つけても驚かないよう気を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TLS
draft-wood-tls-external-psk-importer-00 - Importing External PSKs for TLS 1.3
https://0.me.uk/ev-phishing/
Automated Analysis of TLS 1.3
Chrome’s Plan to Distrust Symantec Certificates
HTTPS Interception Weakens TLS Security | CISA
TCP＋TLSに代わる高速プロトコル、Google生まれの「QUIC」の特徴と標準化の行方【IETFトピックス2016-17】