してみるテストロゴ
Apache 2.4系でHTTP/2サーバを構築してみるテスト。

ブラウザ毎のTLS実装の違いについて

【2018年7月30日】

先日、ブラウザがTLS接続で使用する暗号方式などの情報を表示するページを作ってみました。

クライアント(ブラウザ)とサーバが、TLS接続を行うには、鍵交換、署名方式、暗号スイートの3つの手順について、共有する必要があります。

このページから、ブラウザごとに、TLS接続の個性が見えてきたので、まとめてみたいと思います。

鍵交換

サーバとクライアント(ブラウザ)が、「共通鍵暗号」と呼ばれる演算負荷の軽い暗号方式を使うためには、秘密鍵と呼ばれるデータを交換しておく必要があります。これを鍵交換と呼びます。

鍵交換は、演算負荷の高い「公開鍵暗号」で行います。

TLSの通信は、最初に演算負荷の高い「公開鍵暗号」による鍵交換を行い、HTMLファイルや画像などを取得するHTTP/2.0の通信は、演算負荷の軽い「共通鍵暗号」を使って送受信します。TLSv1.3の共通鍵暗号は後述の「暗号スイート」で決まります。

まず、サーバとクライアントの両者が利用できる交換方式を、グループ(Groups)として列挙して両者が利用できる鍵交換の方式を決定します。

実際には、ECDHEパラメータ(つまり楕円曲線の種類)とDHEパラメータを列挙することになります。

このパラメータは、ブラウザごとに利用できるものが異なります。

現時点では、FireFoxがDHEパラメータをグループに含んでいる以外は、ECDHEの楕円曲線の種類を列挙することになります。

DHEについては、TLSv1.2以前の実装では、脆弱になる可能性があるため、最近のブラウザのTLSv1.2ではほぼ使用しなくなっています。

なのでいまさらDHEかよと思う方もいらっしゃるとおもいますが、TLSv1.3以降では実装が改善され、グループに、DHEパラメータを指定できるようになります。

DHEはECDHEと比べてビット数が多く、そのため量子コンピュータが解読に必要とする量子ビット数も多くなります。実際、数千ビットの量子ビットを持つ量子コンピュータはまだまだ登場しそうにありません。このように、TLSv1.3のDHEは弱点を克服し、ECDHEと比べて、ビット数が大きいことから、量子コンピュータ対策の備えの一つになりえます。

ECDHEについては、広く普及しているP-256、P-384といった楕円曲線に加えて、X25519 やX448といった、Curve25519とCurve448を利用する比較的新しい楕円曲線をグループに列挙することができます。

グループ セキュリティ
ビット
OpenSSL 1.1.1
(サーバ)
Microsoft Edge
Internet Explorer 11
Chrome 68 FireFox 61 Safari
ECDHE P-256 128
P-384 192
P-521 256    
X25519 128  
X448 224        
DHE ffdhe2048 112        
ffdhe3072 128        
ffdhe4096 144          
ffdhe6144 176          
ffdhe8192 192          

各ブラウザの鍵交換のグループをまとめると、上の表のようになります。

マイクロソフト系ブラウザ(Edge/IE11)は、P-256と、P-384の2種類の楕円曲線に対応しています。

Chromeは、これにX25519を加えたもの、FireFoxとSafariはさらにP-521の楕円曲線に対応しています。

そして、FireFoxは前述の通り、DHEパラメータにも対応しており、2048ビットと3072ビットのDHE鍵交換に対応しています。

(OpenSSL1.1.1には、ffdhe2048などの定義が含まれてはいるのですが、Apache HTTPD webサーバからはまだ使えないようです。)

まとめると、鍵交換の選択肢は、FireFoxが最も多く、マイクロソフト系ブラウザ(Edge/IE11)が最も少ない結果となりました。

サーバサイドでは、OpenSSLがX448に対応しておりますが、対応するブラウザはまだなく、宝の持ち腐れになっています。

署名方式

TLSでは、証明書が発行されている秘密鍵を使ってサーバが署名し、クライアント(ブラウザ)が署名を検証することで、通信相手や通信経路が乗っ取られていないことを確認します。

署名アルゴリズムは、この時に利用する暗号方式ですが、これもサーバとクライアントですり合わせます。

ECDSAは、楕円曲線としてP-256,P-384,P521を使う署名アルゴリズムです。

それとは別にEd25519とEd448は、それぞれCurve25519とCurve448と呼ばれる楕円曲線を使う署名アルゴリズムです。

RSAは、素数を利用して署名を行う方法になります。RSA-PSSは、署名用途として利用するRSAの安全性を高めた署名アルゴリズムです。

いずれの署名方式も、利用するためには、サーバ側に証明書発行機関から入手した証明書と呼ばれるデータ(ファイル)が必要となります。

無償の証明書発行機関としては、Let's Encryptが有名です。

署名アルゴリズム OpenSSL 1.1.1
(サーバ)
Microsoft Edge
Internet Explorer 11
Chrome 68 FireFox 61 Safari
ECDSA+SHA256
ECDSA+SHA384
ECDSA+SHA512    
RSA-PSS+SHA256  
RSA-PSS+SHA384  
RSA-PSS+SHA512  
RSA+SHA256
RSA+SHA384
RSA+SHA512
RSA+SHA1
ECDSA+SHA1      
DSA+SHA1        
Ed25519        
Ed448        

ChromeとSafariは521ビットのP-521楕円曲線の署名に対応していないためか、ECDSA+SH512に対応していないようです。

マイクロソフト系は、署名アルゴリズムとしてはP-521に対応しているようですが、RSA-PSSが全滅です。(単なるRSAより、RSA-PSSのほうが安全だと言われています。)そのかわり、DSA+SHA1を含め、暗号強度が弱めのSHA1に手厚い感じです。互換性のためでしょか?

FireFoxは死角なく対応している感じです。

Ed25519とEd448については、ブラウザの対応待ち、というか証明書発行機関の対応待ちなのでしょうか?

暗号スイート

暗号スイートは、通信内容を秘匿化するAES等の暗号と、セッションの乗っ取りを防止するためメッセージ認証(GCM-SHA256等)の暗号の組み合わせになります。

TLSv1.2までは、上記の「鍵交換」と「署名アルゴリズム」もセットにして指定していました。

TLSv1.3では、鍵交換と署名アルゴリズムを含みません。TLS_で始まるものが、TLSv1.3のものです。

通信内容を秘匿化する暗号としては、AES128/256とCHACHA20があります。

メッセージ認証には、ポピュラーなGCM-SHA256の他、CHACHA20と組み合わせて使うPOLY1305、あまり聞かないCCMがあります。CCMを含む暗号スイートは量子コンピュータ対策となります。これは、GCM-SHA256等のメッセージ認証が、量子コンピュータとサイモンのアルゴリズム等によって偽造される可能性に対する対策となります。

メッセージ認証以外に、公開鍵暗号も、量子コンピュータによって解読される可能性があります。(まだもう少し未来の話で、現時点では大丈夫だと考えられています。)そのため、CCMだけでは対策になりません。たとえば、仮にECDHEが、量子コンピュータによって暗号解読されると、同じビット数のECDSAも解読されていると考えられます。そこで、量子コンピュータに対する耐性が類似する数学的基礎が同じアルゴリズムを組み合わせます。

TLSv1.2のCCMを含む暗号スイートでは、数学的基礎が同じアルゴリズムを使う、鍵交換と署名方式の組み合わせだけが定義されています。具体的には楕円曲線を使う場合は、ECDHE-ECDSAの鍵交換と署名アルゴリズムを使い、素数を使う場合はDHE-RSAの鍵交換と署名アルゴリズムを使います。ちなみに、一般に、素数を使う方がビット数が多くなるため、量子コンピュータによる解読に対する耐性があると考えられます。

TLSv1.3は、公開鍵暗号を利用する鍵交換と署名方式を暗号スイートとは別に指定するので、メッセージ認証としてCCMを含む暗号スイートを選べば良いという訳では無くなっています。そこで、TLSv1.3でも、TLSv1.2の暗号スイートのように、量子コンピュータ対策を考慮するときは鍵交換のグループと署名方式を、同じ数学的基礎のものだけを指定するようにします。

なお、楕円曲線の方が、総当たり攻撃に対する耐性(セキュリティービット)が稼げるため、数百ビットの量子コンピュータが存在していないと考えられる現時点であれば、ECDHE-ECDSAの方が、現時点ではバランスが良いとも言えます。ぎりぎりまで、ECDHE-ECDSAを使い、怪しくなってきたところで、DHE-RSA-PSSに切り替えるといった使い方が、想定できます。ただ、DHE-RSAは重そうです。格子暗号など、他の量子耐性のある公開鍵暗号の実用化が待たれます。

暗号スイート TLS Ver. 量子
対策
OpenSSL 1.1.1
(サーバ)
Microsoft Edge
Internet Explorer 11
Chrome 68 FireFox 61 Safari
TLS_AES_128_CCM_SHA256 1.3        
TLS_AES_128_CCM_8_SHA256        
TLS_AES_256_GCM_SHA384      
TLS_CHACHA20_POLY1305_SHA256      
TLS_AES_128_GCM_SHA256      
ECDHE-ECDSA-AES256-CCM 1.2        
ECDHE-ECDSA-AE256-CCM8        
DHE-RSA-AES256-CCM        
DHE-RSA-AES256-CCM8        
ECDHE-ECDSA-AES128-CCM        
ECDHE-ECDSA-AES128-CCM8        
DHE-RSA-AES128-CCM        
DHE-RSA-AES128-CCM8        
ECDHE-ECDSA-AES256-GCM-SHA384  
ECDHE-ECDSA-AES128-GCM-SHA256  
ECDHE-ECDSA-CHACHA20-POLY1305    
ECDHE-RSA-AES256-GCM-SHA384  
ECDHE-RSA-AES128-GCM-SHA256  
ECDHE-RSA-CHACHA20-POLY1305    
ECDHE-ECDSA-AES256-SHA384      
ECDHE-ECDSA-AES128-SHA256      
ECDHE-RSA-AES256-SHA384      
ECDHE-RSA-AES128-SHA256      
ECDHE-ECDSA-AES256-SHA      
ECDHE-ECDSA-AES128-SHA      
ECDHE-RSA-AES256-SHA  
ECDHE-RSA-AES128-SHA  
AES256-GCM-SHA384    
AES128-GCM-SHA256    
AES256-SHA256      
AES128-SHA256      
AES256-SHA  
AES128-SHA  
DES-CBC3-SHA      

ChromeとFireFoxは必要最低限の暗号スイートを効率よく実装して、TLSv1.3に対応している感じです。

一方、マイクロソフト系ブラウザとSafariが、TLSv1.3に対応していませんが、互換性を維持するためか、比較的多くの種類の暗号スイートに対応しています。

また、マイクロソフト系ブラウザだけが、比較的新しいCHACHA20-POLY1305に対応していません。

SafariはTLSv1.2の暗号スイートは網羅しており、CHACHA20-POLY1305にも対応しています。

量子コンピュータ対策については、いずれのブラウザもこれからといえます。

まとめると、TLSで利用する3種類の暗号方式について、ChromeやFirefoxは新しめの方式を積極的に実装し、マイクロソフト系は互換性を大切にする傾向が見て取れます。

Safariは、新しい暗号に対応しつつ、DES-CBC3-SHA(セキュリティービットは112ビット)の対応を終了しており、サーバ設定にかかわらず、TLSv1.2の暗号スイートにおいて、セキュリティービット128ビットを確保している唯一のブラウザとなっています。

NEXT >> トップページに戻る

©Copyrights 2015-2018, non-standard programmer

このサイトは、あくまでも私の個人的体験を、綴ったものです。 軽く参考程度にご利用ください。