YandexでTLSを行う方法と理由

私はYandexで食品の安全性に取り組んでいますが、今は、 HabrのYaCでTLSをどのように実装しているかについて、以前よりも詳細に説明する時が来たようです。



HTTPS接続の使用は、クライアントとサービス間の転送段階でデータの機密性と整合性を保証するHTTPSであるため、安全なWebサービスの重要な部分です。 すべてのサービスを徐々にHTTPS接続にのみ転送します。 それらの多くはすでにパスポート、ポスト、ダイレクト、メトリック、タクシー、Yandex.Money、およびユーザーの個人データを扱うあらゆる形態のフィードバックで独占的に機能しています。 Yandex.Mailは1年以上、これをサポートするSSL / TLSを介して他のメールサービスとデータを交換しています 。







HTTPSはTLSでラップされたHTTPであることは誰もが知っています。 SSLではなくTLSを使用する理由 TLSは基本的に新しいSSLであり、新しいプロトコルの名前はその目的を最も正確に説明しているためです。 また、 POODLEの脆弱性を考慮すると、SSLが使用できなくなったと公式に想定できます。



HTTPとともに、ほとんどすべてのアプリケーション層プロトコルをTLSでラップできます。 たとえば、SMTP、IMAP、POP3、XMPPなど。 ただし、HTTPSの展開は最も広く知られている問題であり、ブラウザーの動作のために多くの微妙な問題があるため、これについて説明します。 ただし、いくつかの仮定では、他のプロトコルについても多くのことが当てはまります。 私たちの同僚に役立つ最低限必要なものについて話をしようとします。



ストーリーを条件付きで2つの部分に分割します。インフラストラクチャ（HTTPの下にあるものすべて）と、アプリケーションレベルでの変更に関する部分です。

終了

HTTPSを展開するチームが最初に対処しなければならないことは、TLS終了方法の選択です。 TLS終了は、TLSでアプリケーション層プロトコルをカプセル化するプロセスです。 通常、次の3つのオプションから選択できます。

1. Amazon ELB 、 Cloudflare 、 Akamaiなど、多くのサードパーティサービスのいずれかを使用します。 この方法の主な欠点は、サードパーティのサービスとサーバー間のチャネルを保護する必要があることです。 ほとんどの場合、これには何らかの形でTLSサポートを展開する必要があります。 大きな欠点は、必要な機能、脆弱性の修正速度をサポートするという点でサービスプロバイダーに完全に依存することであり、別の問題は証明書を開示する必要があるかもしれません。 それにもかかわらず、この方法は、 PaaSを使用する新興企業や企業にとっては良いソリューションになります。
2. 独自のハードウェアとデータセンターを使用している企業の場合、可能なオプションは、TLS終了機能を備えたハードウェアロードバランサーです。 ここでの唯一の利点はパフォーマンスです。 このようなソリューションを選択すると、ベンダーに完全に依存することになります。また、製品内で同じハードウェアコンポーネントが使用されることが多いため、チップメーカーにも依存します。 その結果、機能を追加するタイミングは理想からはほど遠いです。 このような製品の輸入に伴う潜在的な税関の問題は、この資料の外に残されます。
3. ソフトウェアソリューション-黄金の平均。 既存のオープンソースソリューション-Nginx 、 Haproxy 、 Budなど -機能、最適化を追加して、状況をほぼ完全に制御できます。 欠点はパフォーマンスです-ハードウェアソリューションよりも低くなります。

Yandexでは、ソフトウェアソリューションを使用しています。 私たちの道を進むと、コンポーネントの統合は、TLSを展開するための重要なステップになります。

統一

歴史的に、私たちのサービスはWebサーバーに異なるソフトウェアを使用していたため、すべてを統一するために、Nginxを支持してほとんどのソリューションを放棄し、拒否できない場合はNginxに対して「隠す」ことにしました。 この場合の例外は、バランサーと呼ばれる独自の開発を使用する検索でした-突然-バランサー。



バランサーは、他の、商業的なソリューションでさえできない多くのことを行うことができます。 いつか、みんながこれについてもっと詳しく話すと思う。 才能のある開発チームがあるため、Nginxに加えて、独自のWebサーバーの1つをサポートする余裕があります。



暗号化自体に関しては、 OpenSSLライブラリを使用します 。 現在、適切なライセンスを備えたTLSの最も安定した生産的な実装です。 OpenSSLバージョン1+を使用することが重要です。これは、メモリの処理を最適化するため、必要なすべての最新の暗号とプロトコルがサポートされているためです。 今後の推奨事項はすべて、Nginx Webサーバーのユーザーを対象としています。

認証

サービスでHTTPSを使用するには、証明書が必要です。 証明書は公開鍵であり、認証局によって署名されたASN.1形式の特定のデータセットです。 通常、このような証明書は中間CAによって署名され、サービスのドメイン名がCommon NameまたはAlt Names拡張に含まれています。



証明書の有効性を検証するために、ブラウザは最終証明書のデジタル署名の有効性の検証を試み、次に各中間認証局の検証を試みます。 証明機関のチェーンの後者の証明書は、いわゆるルート証明機関（ルートCA）によって署名されなければなりません。



ルート証明機関の証明書は、オペレーティングシステムまたはユーザーのブラウザー（Firefoxなど）に保存されます。 Webサーバーを設定するときは、サーバー証明書だけでなく、すべての中間証明書もクライアントに送信することが重要です。 この場合、ルート証明書を送信する必要はありません-既にOSにあります。







大企業は、独自の中間CAを所有する余裕があります。 たとえば、2012年まで、すべてのYandex証明書はYandexExternalCAによって署名されていました。 独自の中間CAを使用すると、証明書の最適化とピン留めの両方の追加の機会が与えられ、ほぼすべての最終ドメイン名に対して証明書を発行できるため、追加の責任が課されます。また、侵害された場合、中間CAの証明書の失効まで、深刻な結果につながる可能性があります



独自のCAを維持するのは非常に高価で複雑になる可能性があるため、一部の企業はCAをMPKI-Managed PKIモードで使用しています。 ほとんどの消費者にとって、商業サプライヤーのいずれかを使用して証明書を購入するだけで十分です。



すべての証明書は、次の特性に分類できます。

1. 使用されるデジタル署名アルゴリズムとハッシュ関数。
2. 証明書のタイプ。

デジタル署名アルゴリズム-証明書の署名には公開鍵を使用した暗号化アルゴリズムが使用されます。ほとんどの場合、これはRSA 、 DSAまたはECDSAです。 GOSTファミリーのアルゴリズムについては、クライアントソフトウェアで大規模なサポートを受けていないため、ここでは取り上げません。



RSA証明書は現在最も広く使用されており、すべてのプロトコルおよびOCバージョンでサポートされています。



このアルゴリズムの欠点は、デジタル署名を生成および検証する際のキーサイズと同等のパフォーマンスです。 鍵サイズが2048ビット未満の証明書は安全ではないため、より大きな鍵を使用した操作は大量のプロセッサリソースを消費します。



署名を生成する場合、DSAに似たスキームはRSAよりも高速です（同じパラメーターサイズ）。すべての操作は楕円曲線の点のグループで行われるため、ECDSAは従来のDSAよりもはるかに高速です。 私たちのテストによると、1つのXeon 5645サーバーでは、2048ビットのキーサイズ（ECDHE-RSA-AES128-GCM-SHA256）でRSAによって署名された証明書を使用して、Nginx Webサーバーで1秒あたり最大3200 TLSハンドシェイクを行うことができます。 同時に、ECDSA証明書（ECDHE-ECDSA-AES128-GCM-SHA256）を使用して、すでに6300ハンドシェイクを行うことができます-パフォーマンスの違いはほぼ2倍になります。



残念ながら、Windows XP <SP3および大規模サイトのクライアント間の共有がゼロ以外である一部のブラウザは、ECC証明書をサポートしていません。



最も一般的なEDSアルゴリズムの耐久性は、使用されるハッシュ関数の耐久性（セキュリティ）に直接依存します。 使用される主なハッシュアルゴリズムは次のとおりです。

1. MD5
   
   
   
   現在、安全ではないと見なされ、使用されていません。
2. SHA-1
   
   
   
   、現在では安全ではないと認識されています。
3. SHA-256
   
   
   
   現在SHA-1
   
   
   
   すでに置き換えているアルゴリズム。
4. SHA-512
   
   
   
   今日はめったに使用されないため、ここでは詳しく説明しません。

SHA-1



すでに公式に安全ではないと見なされており、徐々に段階的に廃止されています。 そのため、Yandex.Browserおよびその他のChromiumファミリーのブラウザは、 SHA-1



を使用して署名され、2016年1月1日以降に期限切れになる証明書を安全でないものとしてマークし始めます。 すべての新しい証明書は、 SHA-256



を使用して正しく署名する必要があります。 残念ながら、すべてのブラウザーとOS（WinXP <sp3）がこのハッシュ関数をサポートしているわけではなく、非常に大きなリソースの場合、これはクライアントの損失につながる可能性があります。



TLSに使用されるすべてのサーバーエンド証明書は、検証方法-Extended Validatedとその他（ほとんどの場合Domain Validated）で条件付きで分割できます。



技術的には、拡張検証済み証明書に、EV属性と多くの場合会社の住所を含む追加フィールドが追加されます。 EV証明書を取得することは、証明書所有者の存在を法的に検証することを意味しますが、Domain Validatedなどの証明書は、証明書所有者がドメイン名を制御することのみを確認します。



美しい緑のダッシュの外観に加えて、EV証明書の記号は、失効ステータスの確認に関連するブラウザーの動作にも影響します。 そのため、OCSPまたはCRLを使用せず、Google CRLsetのみに依存するChromiumファミリのブラウザでさえ、EVはOCSPプロトコルを使用してステータスをチェックします。 以下に、これらのプロトコルの機能について詳しく説明します。



証明書がわかったので、どのプロトコルバージョンが使用されるかを理解する必要があります。 覚えているように、SSLv2およびSSLv3バージョンのプロトコルには根本的な脆弱性があります。 したがって、それらを無効にする必要があります。 現在、ほとんどすべてのクライアントがTLS 1.0をサポートしています。 TLSバージョン1.1および1.2の使用をお勧めします。



SSLv3を使用するクライアントの数が非常に多い場合は、RC4アルゴリズムでの補償手段としてのみ使用することを許可できます。これは移行期間中に行いました。 ただし、古いブラウザを使用しているユーザーが私たちほど多くない場合は、SSLv3を完全に無効にすることをお勧めします。 プロトコルに関するNginxの正しい構成は次のようになります。

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;







TLS接続に使用される暗号スイートまたは暗号スイートとハッシュ関数の選択に関して、Webサーバーは安全な暗号のみを使用する必要があります。 ここでは、セキュリティ、速度、パフォーマンス、互換性のバランスを取ることが重要です。

セキュリティvs. 性能

HTTPSの使用は、サーバー側のパフォーマンスと、クライアント側でのリソースのロードおよびレンダリングの速度の両方の点で非常にコストがかかると一般に考えられています。 これは一部真実です-HTTPSが正しく構成されていないと、ハンドシェイクに2（またはそれ以上）の往復時間（RTT）が追加される可能性があります。



HTTPSの実装中に発生する遅延を軽減するために、次の方法が使用されます。

1. コンテンツ配信ネットワーク（CDN）。 終端点をクライアントの近くに配置することにより、RTTを削減できます。 したがって、HTTPSの実装中に発生する遅延を感知できなくします。 Yandex はこの手法をうまく使用し 、存在するポイントの数を常に増やしています。
   
   
   
   
2. 証明書ステータスチェックの最適化。 安全な接続が確立されると、一部のブラウザはサーバー証明書の失効ステータスを確認します。 このようなチェックにより、所有者によって証明書が取り消されていないことを確認することができますサーバー証明書を取り消す必要があるのは、たとえば、秘密鍵が危殆化した後です。 そのため、Heartbleedの脆弱性が発見された後、大量注文証明書が取り消されました。

現在、証明書のステータスを確認するために使用される2つの主要なプロトコルがあります。

• 証明書失効リスト。 この方法を使用する場合、ブラウザーはHTTPプロトコルを使用して、証明書で指定されたURLから失効した証明書のシリアル番号のリストをダウンロードします。 このリストは、CAによって管理および署名されています。 リストファイルは大きくなる可能性があるため、一定期間（ほとんどの場合1週間）キャッシュされます。
• オンライン証明書ステータスプロトコル。

両方のプロトコルがHTTPを介して動作し、同時に証明書のステータスをチェックすることは、CRLまたはOCSPを配布するサーバーが配置されているブロッキング手順であるため、レスポンダーはTLSハンドシェイクの速度に直接影響します。



ブラウザーごとに証明書のステータスが異なる方法でチェックされます。 したがって、Firefoxは通常の証明書にOCSPのみを使用しますが、CRLもEVに対してチェックされます。 IEとOperaはCRLとOCSPの両方をチェックし、Yandex.BrowserとChromiumファミリの他のブラウザは、CRLsetsに依存する従来のプロトコルを使用しません-ブラウザの更新に伴う人気のあるリソースの失効した証明書のリスト。



チェックを最適化するために、 OCSPステープルと呼ばれるメカニズムも考案されました。これにより、クライアントは、証明書とともにTLS拡張の形式でOCSPレスポンダー応答を送信できます。 最新のデスクトップブラウザはすべて、OCSPステープルをサポートしています（Safariを除く）。



nginxでOCSPステープルを有効にするには、次のディレクティブを使用します： ssl_stapling on;



。 この場合、必ずresolverを指定してください。



ただし、非常に大きくロードされたリソースがある場合は、キャッシュするOCSP応答（Nginxが1時間応答をキャッシュする）が正しいことを確認する必要があります。

 ssl_stapling_verify on; ssl_trusted_certificate /path/to/your_intermediate_CA_and_root_certs;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OCSPステープルを使用する場合、大量のリソースでクライアントシステムの時間が正しくないなどの問題が発生する場合があります。 これは、標準に従って、レスポンダの応答時間が明確に定義された時間間隔に制限され、クライアントマシンの時間が5〜10〜20分遅れることがあるためです。 ユーザーのこの問題を解決するために、サーバーに、それらが生成されてから約1日後に答えを出すように教える必要がありました（新しい証明書をレイアウトするときとほぼ同じことです）。



したがって、システム時間が1日までダウンしているユーザーに、間違った時間に関する警告を表示する機会があります。 OCSP応答をランダムにローテーションするために、 ssl_stapling_fileディレクティブが使用されます。 OCSPステープルをサポートしていないクライアントの場合、CDNのOCSPレスポンダーの応答のキャッシュを使用して、応答時間を短縮します。



チェックを最適化する別の効果的な方法は、短命の証明書、つまりステータス検証ポイントが設定されていない証明書を使用することです。 しかし、そのような証明書の寿命は非常に短く、1〜3か月です。



認証局はそのような証明書を使用する余裕があります。 証明書にステータスチェックポイントがある場合、Internet ExplorerはOCSPレスポンダーの証明書のステータスも確認できるため、ほとんどの場合、OCSPレスポンダーに使用され、追加の遅延が発生します。

ただし、OCSPステープルまたは短命の証明書を使用する場合でも、標準のTLSハンドシェイク（4ステップ）により2つのRTT遅延が追加されます。



TLS False Startメカニズムにより、サーバーの応答を待たずに3段階後にアプリケーションデータを送信できるため、1つのRTTを節約できます。 TLS False Startは、ChromiumファミリーおよびYandex.Browser、IE、Safari、Firefoxのブラウザーでサポートされています。







残念ながら、ブラウザとは異なり、すべてのWebサーバーがこのメカニズムをサポートしているわけではありません。 したがって、通常、次の要件はTLS False Startを使用するシグナルです。

• サーバーはNPN / ALPNをアナウンスします（SafariおよびIEには必要ありません）。
• サーバーはPerfect Forward Secrecy暗号スイートを使用します。

完全な秘密

SSLv3より前は、サーバーの秘密キーにアクセスした攻撃者は、サーバーを通過したすべての通信を受動的に解読できました。 後に、キーネゴシエーションプロトコル（通常Diffie-Hellmanスキームに基づく）を使用し、攻撃者がサーバーの秘密キーにアクセスしてもセッションキーを回復できないようにするForward Secrecyメカニズムが発明されました（Perfectプレフィックスを使用する場合もあります）。



ユーザーデータを操作するサービスの典型的なnginx構成は次のようになります。

 ssl_prefer_server_ciphers on; ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構成では、楕円曲線ディフィーヘルマン（ECDH）アルゴリズムに従って形成された128ビットセッションキーを使用して、AESの最大優先度を設定します。 次に、ECDHを使用した他の暗号が登場します。 略語の2番目の「E」はEphemeralを表します。 同じ接続内に存在するセッションキー。

次に、通常のDiffie Hellman（EDH）の使用を許可します。 ここで重要なことは、2048ビットのキーサイズでDiffie Hellmanを使用すると非常に高価になる可能性があることです。



構成のこの部分は、PFSサポートを提供します。 AES-NIをサポートするプロセッサを使用している場合、AESはリソースの観点から無料です。 3DESを無効にし、非PFSモードでAES128を有効にします。 非常に古い顧客との互換性のために、3DESとEDHおよび3DESをCBCモードのままにします。 安全でないRC4などを無効にします。 OpenSSLの最新バージョンを使用することが重要です。その後、 AEAD暗号を含む「AES128」がデプロイされます。



PFSには1つの欠点があります-パフォーマンスのペナルティ。 最新のWebサーバー（Nginxを含む）は、イベント駆動型モデルを使用します。 同時に、非対称暗号化は、Webサーバープロセスがブロックされ、それがサービスを提供するクライアントが苦しむため、ほとんどの場合、ブロック操作です。 この場所で何を最適化できますか？

1. SPDY。
   
   
   
   
   
   
   
   MailでSPDYを実装した経験について読んだ場合、SPDYを使用すると接続の数、したがってハンドシェイクの数を減らすことができることに気付きました。 nginx 1.5以降では、構成に4文字を追加することでSPDYが有効になります（サーバーはspdyモジュール--with-http_spdy_moduleで構築する必要があります）。
   
   
   
   listen 443 default spdy ssl;
   
   
   
   
2. 楕円暗号を使用します。 楕円曲線を使用した非対称暗号化アルゴリズムは、従来の逆画像よりも効率的であるため、暗号スイートを設定する際にECDHの優先度を上げています。 前に書いたように、ECDHの使用に加えて、楕円曲線（ECDSA）のデジタル署名付きの証明書を使用できます。これにより、生産性が向上します。
   
   
   
   残念ながら、大規模サイトのクライアント間でのシェアがゼロ以外のWindows XP <SP3およびその他のブラウザは、ECC証明書をサポートしていません。 解決策は、クライアントごとに異なる証明書を使用することです。これにより、新しいクライアント（大部分）のためにリソースが節約されます。 Opensslバージョン1.0.2では、クライアント設定に応じてサーバー証明書を選択できます。 残念ながら、Nginxは「そのまま」では単一のサーバーに複数の証明書を使用できません。
3. セッションの再利用を使用します。 セッションを再利用すると、PFS / False Start接続のサーバーリソース（非対称暗号化を除く）を節約できるだけでなく、通常の接続の遅延TLSハンドシェイクを1RTTに減らすことができます。

現在、2つのセッション再利用メカニズムがあります。

1. SSLセッションキャッシュ。 このメカニズムは、接続ごとに一意の識別子がクライアントに与えられ、セッションキーがこの識別子を使用してサーバーに保存されるという事実に基づいています。 プラスは、古いブラウザーを含むほぼすべてのサポートです。 欠点は、物理サーバーとデータセンター間で重要なデータを含むキャッシュを同期する必要があることです。これにより、セキュリティの問題が発生する可能性があります。
   
   
   
   
   
   
   
   Nginxの場合、セッションキャッシュは、クライアントが元のSSLハンドシェイクが行われたのと同じ実際の場所に到達した場合にのみ機能します。 SSLセッションキャッシュを有効にすることをお勧めします。これは、ユーザーが同じ実数に到達する可能性が高い実数が少ない構成に役立つためです。
   
   
   
   nginxでは、構成は次のようになります。SOME_UNIQ_CACHE_NAMEはキャッシュ名です。証明書ごとに異なる識別子を使用することをお勧めします（nginx 1.7.5 +、1.6.2 +では不要）、128Mbはキャッシュサイズ、28時間はセッションの有効期間です。
   
   ssl_session_cache shared:SOME_UNIQ_CACHE_NAME:128m;



ssl_session_timeout 28h;
   
   
   
   
   
   
   
   セッションの寿命を延ばすときは、エラーログに次のようなエントリがあるという事実に備える必要があります。
   
   2014/03/18 13:36:08 [crit] 18730#0: ngx_slab_alloc() failed: no memory in SSL session shared cache "SSL"
   
   
   
   。
   
   
   
   これは、nginxのセッションキャッシュからデータを絞り出す特性のためです。制限に達すると、セッションにメモリを割り当てようとし、最も古いセッションの1つが強制終了され、操作が再度繰り返されます。 つまり、セッションはバッファに正常に追加されますが、アロケータの関数が最初に呼び出されたときにエラーがログに書き込まれます。 このようなエラーは無視できます-機能に影響はありません（Nginx 1.4.7で修正済み）。
2. TLSセッションチケット 。 このメカニズムは、Yandex.BrowserやFirefoxを含むChromiumファミリのブラウザでのみサポートされています。 この場合、クライアントには、サーバーが認識しているキーとキー識別子で暗号化されたセッション状態が送信されます。 この場合、キーのみがサーバー間で共有されます。
   
   
   
   
   
   
   
   Nginxは、バージョン1.5.8+でセッションチケットの静的キーサポートを追加しました。 複数のサーバーを使用する場合のtlsセッションチケットのセットアップは、次のように行われます。
   
   

    ssl_session_ticket_key current.key; ssl_session_ticket_key prev.key; ssl_session_ticket_key prevprev.key;
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
   
   この場合、current.keyは現在使用中のキーです。 Prev.keyは、current.keyが使用されるN時間前に使用されるキーです。 Prevprev.key-prev.keyを使用するN時間前に使用されるキー。 Nの値は、 ssl_session_timeoutで指定された値と等しくなければなりません。 28時間から開始することをお勧めします。
   
   
   
   重要なポイントは、キーの回転方法です。 チケットの暗号化のためにキーを盗んだ攻撃者は、キーの有効期間内にすべてのセッション（PFSを含む）を解読できます。

Yandexには、キーを生成してエンドサーバーに安全に配信するための特別なメカニズムがあります。

用途

Csp

インフラストラクチャの問題が解決したら、アプリケーションに戻ります。 最初に行う必要があるのは、いわゆる 混合コンテンツ。 それはすべて、プロジェクトの規模、コードの量と品質に依存します。 どこかでsedやnginxツールを使用して取得できますが、どこかでDOMツリーでハードコードされたhttpスキームを探す必要があります。 コンテンツセキュリティポリシーメカニズムは私たちの助けになりました;メールの同僚は以前にその実装について書きました 。



このような見出しをテストベンチに追加すると、 data:



およびhttps:



以外のプロトコルを使用してロードされたコンテンツに関するレポートを受け取りhttps:





Content-Security-Policy-Report-Only: default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report

安全なクッキー

混合コンテンツを削除した後、Cookieに対してSecure属性が設定されていることを確認することが重要です。 これらのCookieは安全でない接続を介して送信できないことをブラウザに伝えます。 そのため、Yandexにはこれまで2つのcookieがあります。sessionid2とSession_idで、1つは安全な接続を介してのみ送信され、もう1つは下位互換性のために「安全でない」ままです。 「安全な」Cookieがないと、メール、ディスク、その他の重要なサービスにアクセスできません。



Set-Cookie: session=1234567890abcdef; HttpOnly; Secure;

Hsts

最後に、HTTPSプロトコルを使用してサービスが正しく機能することを確認した後、HTTPバージョンからHTTPSへのリダイレクトを設定します。保護されていないHTTPプロトコルを使用してこのリソースにアクセスできなくなることをブラウザーに伝えることが重要です。



これを行うために、HTTP Strict Transport Securityヘッダーが作成されました。

Strict-Transport-Security: max-age=31536000; includeSubdomains;







max-ageパラメーターは、セキュアプロトコルを使用する期間（1年）を設定します。 オプションのincludeSubdomainsフラグは、特定のドメインのすべてのサブドメインにも暗号化された接続を介してのみアクセスできることを示します。



ChromiumおよびFirefoxファミリーのブラウザーのユーザーが最初にアクセスされた場合でも、常に安全な接続を使用できるようにするには、ブラウザーのHSTSプリロードリストにリソースを追加できます。 安全性を確保することに加えて、最初の使用時に1つのリダイレクトを保存します。



これを行うには、ヘッダーに「プリロード」フラグを追加し、 hstspreload.appspot.comでドメインを指定します。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload







たとえば、Yandex.Passportはブラウザのプリロードリストに追加されます。

おわりに

単一のnginxサーバーの構成全体は次のようになります。

 http { [...] ssl_stapling on; resolver 77.88.8.1; #  127.0.0.1    keepalive_timeout 120 120; server { listen 443 ssl spdy; server_name yourserver.com; ssl_certificate /etc/nginx/ssl/cert.pem; #   ssl_certificate_key /etc/nginx/ssl/key.pem; #   ssl_dhparam /etc/nginx/ssl/dhparam.pem; #   openssl dhparam 2048 ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; ssl_session_cache shared:SSL:64m; ssl_session_timeout 28h; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;"; add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report"; location / { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論として、HTTPSは徐々にWEBを操作するための事実上の標準になりつつあり、ブラウザだけでなく、ほとんどのモバイルアプリケーションAPIがHTTPSプロトコルを使用して動作を開始することを付け加えます。 モバイルでHTTPSを使用することの安全な実装のいくつかの機能は、ニジニノヴゴロドでのコミュニティ作業の日のYuri tracer0tong Leonovich によるレポートに記載されています 。