ssl —ソケットオブジェクトのTLS / SSLラッパー—Pythonドキュメント

提供：Dev Guides
< PythonPython/docs/3.8/library/ssl
移動先:案内、検索

ssl —ソケットオブジェクトのTLS / SSLラッパー

ソースコード： ：source： `Lib / ssl.py`

このモジュールは、クライアント側とサーバー側の両方のネットワークソケットに対して、トランスポート層セキュリティ（「SecureSocketsLayer」と呼ばれることが多い）暗号化およびピア認証機能へのアクセスを提供します。 このモジュールはOpenSSLライブラリを使用します。 OpenSSLがそのプラットフォームにインストールされている限り、すべての最新のUnixシステム、Windows、Mac OS X、およびおそらく追加のプラットフォームで使用できます。

ノート

オペレーティングシステムのソケットAPIが呼び出されるため、一部の動作はプラットフォームに依存する場合があります。 インストールされているバージョンのOpenSSLでも、動作にばらつきが生じる可能性があります。 たとえば、TLSv1.1およびTLSv1.2にはopensslバージョン1.0.1が付属しています。


警告

セキュリティに関する考慮事項を読まずにこのモジュールを使用しないでください。 sslモジュールのデフォルト設定は必ずしもアプリケーションに適しているとは限らないため、これを行うと、誤った安心感につながる可能性があります。


このセクションでは、sslモジュールのオブジェクトと機能について説明します。 TLS、SSL、および証明書に関するより一般的な情報については、下部の「関連項目」セクションのドキュメントを参照してください。

このモジュールは、 socket.socket タイプから派生したクラス ssl.SSLSocket を提供し、ソケットを通過するデータを暗号化および復号化するソケットのようなラッパーを提供しますSSLを使用します。 接続の反対側の証明書を取得するgetpeercert()や、安全な接続に使用されている暗号を取得するcipher()などの追加のメソッドをサポートします。

より高度なアプリケーションの場合、 ssl.SSLContext クラスは、設定と証明書の管理に役立ちます。これらは、 SSLContext.wrap_socket（）メソッドで作成されたSSLソケットに継承できます。

バージョン3.5.3で変更： OpenSSL1.1.0とのリンクをサポートするように更新


バージョン3.6で変更： OpenSSL 0.9.8、1.0.0、および1.0.1は非推奨になり、サポートされなくなりました。 将来的には、sslモジュールには少なくともOpenSSL1.0.2または1.1.0が必要になります。


関数、定数、および例外

ソケットの作成

Python 3.2および2.7.9以降、 SSLContext インスタンスの SSLContext.wrap_socket（）を使用して、ソケットを SSLSocket オブジェクトとしてラップすることをお勧めします。 ヘルパー関数 create_default_context（）は、安全なデフォルト設定で新しいコンテキストを返します。 古い wrap_socket（）関数は、非効率であり、サーバー名表示（SNI）とホスト名の照合をサポートしていないため、非推奨になりました。

デフォルトのコンテキストとIPv4 / IPv6デュアルスタックを使用したクライアントソケットの例： 

import socket
import ssl

hostname = 'www.python.org'
context = ssl.create_default_context()

with socket.create_connection((hostname, 443)) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        print(ssock.version())

カスタムコンテキストとIPv4を使用したクライアントソケットの例： 

hostname = 'www.python.org'
# PROTOCOL_TLS_CLIENT requires valid cert chain and hostname
context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.load_verify_locations('path/to/cabundle.pem')

with socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        print(ssock.version())

ローカルホストIPv4でリッスンしているサーバーソケットの例： 

context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.load_cert_chain('/path/to/certchain.pem', '/path/to/private.key')

with socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0) as sock:
    sock.bind(('127.0.0.1', 8443))
    sock.listen(5)
    with context.wrap_socket(sock, server_side=True) as ssock:
        conn, addr = ssock.accept()
        ...

コンテキストの作成

便利な関数は、一般的な目的で SSLContext オブジェクトを作成するのに役立ちます。

ssl.create_default_context(purpose=Purpose.SERVER_AUTH, cafile=None, capath=None, cadata=None)

指定された目的のデフォルト設定で新しい SSLContext オブジェクトを返します。 設定は ssl モジュールによって選択され、通常、 SSLContext コンストラクターを直接呼び出す場合よりも高いセキュリティレベルを表します。

cafile 、 capath 、 cadata は、 SSLContext.load_verify_locations（）のように、証明書の検証で信頼するオプションのCA証明書を表します。 3つすべてがなしの場合、この関数は、代わりにシステムのデフォルトのCA証明書を信頼することを選択できます。

設定は次のとおりです。 PROTOCOL_TLS 、 OP_NO_SSLv2 、および OP_NO_SSLv3 、RC4なしおよび認証されていない暗号スイートなしの高暗号化暗号スイート。 SERVER_AUTH を purpose として渡すと、 verify_mode が CERT_REQUIRED に設定され、CA証明書が読み込まれます（ cafile の少なくとも1つが、 capath または cadata が指定されている）、または SSLContext.load_default_certs（）を使用してデフォルトのCA証明書をロードします。

keylog_filename がサポートされており、環境変数 SSLKEYLOGFILEが設定されている場合、 create_default_context（）はキーロギングを有効にします。

ノート

プロトコル、オプション、暗号、およびその他の設定は、事前の非推奨なしにいつでもより制限的な値に変更される可能性があります。 値は、互換性とセキュリティの間の公正なバランスを表しています。

アプリケーションに特定の設定が必要な場合は、 SSLContext を作成し、自分で設定を適用する必要があります。

ノート

特定の古いクライアントまたはサーバーがこの関数によって作成された SSLContext に接続しようとすると、「プロトコルまたは暗号スイートの不一致」というエラーが表示される場合は、SSL3.0のみをサポートしている可能性があります。この関数は、 OP_NO_SSLv3 の使用を除外します。 SSL3.0は完全に壊れていると広く考えられています。 この機能を引き続き使用したいが、SSL 3.0接続を許可したい場合は、以下を使用してそれらを再度有効にすることができます。

ctx = ssl.create_default_context(Purpose.CLIENT_AUTH)
ctx.options &= ~ssl.OP_NO_SSLv3

バージョン3.4の新機能。

バージョン3.4.4で変更： RC4はデフォルトの暗号文字列から削除されました。

バージョン3.6で変更： ChaCha20 / Poly1305がデフォルトの暗号文字列に追加されました。

3DESはデフォルトの暗号文字列から削除されました。

バージョン3.8で変更：キーロギングのサポートが SSLKEYLOGFILEに追加されました。


例外

exception ssl.SSLError

基盤となるSSL実装（現在OpenSSLライブラリによって提供されている）からのエラーを通知するために発生します。 これは、基盤となるネットワーク接続に重ねられている高レベルの暗号化および認証レイヤーに問題があることを示しています。 このエラーは OSError のサブタイプです。 SSLError インスタンスのエラーコードとメッセージは、OpenSSLライブラリによって提供されます。

バージョン3.3で変更： SSLError は socket.error のサブタイプでした。

library

SSL、PEM、X509など、エラーが発生したOpenSSLサブモジュールを指定する文字列ニーモニック。 可能な値の範囲は、OpenSSLのバージョンによって異なります。

バージョン3.3の新機能。

reason

このエラーが発生した理由を示す文字列ニーモニック（例：CERTIFICATE_VERIFY_FAILED）。 可能な値の範囲は、OpenSSLのバージョンによって異なります。

バージョン3.3の新機能。

exception ssl.SSLZeroReturnError

SSLError のサブクラスは、読み取りまたは書き込みを試みたときに発生し、SSL接続が正常に閉じられました。 これは、基盤となるトランスポート（TCPの読み取り）が閉じられたことを意味するものではないことに注意してください。

バージョン3.3の新機能。

exception ssl.SSLWantReadError

データの読み取りまたは書き込みを試みるときにノンブロッキングSSLソケットによって発生する SSLError のサブクラスですが、要求を満たす前に、基盤となるTCPトランスポートでより多くのデータを受信する必要があります。

バージョン3.3の新機能。

exception ssl.SSLWantWriteError

ノンブロッキングSSLソケットがデータの読み取りまたは書き込みを試みるときに発生する SSLError のサブクラスですが、要求を満たす前に、基になるTCPトランスポートでより多くのデータを送信する必要があります。

バージョン3.3の新機能。

exception ssl.SSLSyscallError

SSLError のサブクラスは、SSLソケットで操作を実行しようとしたときにシステムエラーが発生したときに発生しました。 残念ながら、元のerrno番号を調べる簡単な方法はありません。

バージョン3.3の新機能。

exception ssl.SSLEOFError

SSLError のサブクラスは、SSL接続が突然終了したときに発生します。 通常、このエラーが発生したときに、基になるトランスポートを再利用しようとしないでください。

バージョン3.3の新機能。

exception ssl.SSLCertVerificationError

証明書の検証が失敗したときに発生する SSLError のサブクラス。

バージョン3.7の新機能。

verify_code

検証エラーを示す数値エラー番号。

verify_message

検証エラーの人間が読める文字列。

exception ssl.CertificateError

SSLCertVerificationError のエイリアス。

バージョン3.7で変更：例外は SSLCertVerificationError のエイリアスになりました。


ランダム生成

ssl.RAND_bytes(num)

num 暗号的に強力な疑似ランダムバイトを返します。 PRNGに十分なデータがシードされていない場合、または操作が現在のRANDメソッドでサポートされていない場合は、 SSLError が発生します。 RAND_status（）を使用してPRNGのステータスを確認でき、 RAND_add（）を使用してPRNGをシードできます。

ほとんどすべてのアプリケーションでは、 os.urandom（）が推奨されます。

ウィキペディアの記事暗号的に安全な疑似乱数ジェネレーター（CSPRNG）を読んで、暗号化ジェネレーターの要件を取得してください。

バージョン3.3の新機能。

ssl.RAND_pseudo_bytes(num)

戻り値（バイト、is_cryptographic）：生成されたバイトが暗号的に強力な場合、バイトは num 疑似ランダムバイト、is_cryptographicはTrueです。 操作が現在のRANDメソッドでサポートされていない場合、 SSLError が発生します。

生成された疑似ランダムバイトシーケンスは、十分な長さである場合は一意になりますが、必ずしも予測できないわけではありません。 これらは、暗号化以外の目的および暗号化プロトコルの特定の目的に使用できますが、通常はキーの生成などには使用できません。

ほとんどすべてのアプリケーションでは、 os.urandom（）が推奨されます。

バージョン3.3の新機能。

バージョン3.6以降非推奨： OpenSSLは ssl.RAND_pseudo_bytes（）を非推奨にしました。代わりに ssl.RAND_bytes（）を使用してください。

ssl.RAND_status()
SSL疑似乱数ジェネレーターに「十分な」ランダム性がシードされている場合はTrueを返し、それ以外の場合はFalseを返します。 ssl.RAND_egd（）および ssl.RAND_add（）を使用して、疑似乱数ジェネレーターのランダム性を高めることができます。
ssl.RAND_egd(path)

どこかでエントロピー収集デーモン（EGD）を実行していて、 path がそれに対して開かれているソケット接続のパス名である場合、これはソケットから256バイトのランダム性を読み取り、SSLに追加します。生成された秘密鍵のセキュリティを強化するための疑似乱数ジェネレータ。 これは通常、ランダム性のより良いソースがないシステムでのみ必要です。

エントロピー収集デーモンのソースについては、 http://egd.sourceforge.net/または http://prngd.sourceforge.net/ を参照してください。

ssl.RAND_add(bytes, entropy)

指定されたバイトをSSL疑似乱数ジェネレーターに混合します。 パラメータ entropy （float）は、文字列に含まれるエントロピーの下限です（したがって、いつでも0.0を使用できます）。 エントロピーのソースの詳細については、 RFC 1750 を参照してください。

バージョン3.5で変更：書き込み可能なバイトのようなオブジェクトが受け入れられるようになりました。


証明書の取り扱い

ssl.match_hostname(cert, hostname)

cert （ SSLSocket.getpeercert（）によって返されるデコードされた形式）が指定されたホスト名と一致することを確認します。 適用されるルールは、 RFC 2818 、 RFC 5280 、および で概説されているHTTPSサーバーのIDをチェックするためのルールです。 ] RFC 6125 。 HTTPSに加えて、この機能は、FTPS、IMAPS、POPSなどのさまざまなSSLベースのプロトコルでサーバーのIDをチェックするのに適している必要があります。

CertificateError は失敗時に発生します。 成功すると、関数は何も返しません。

>>> cert = {'subject': ((('commonName', 'example.com'),),)}
>>> ssl.match_hostname(cert, "example.com")
>>> ssl.match_hostname(cert, "example.org")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/py3k/Lib/ssl.py", line 130, in match_hostname
ssl.CertificateError: hostname 'example.org' doesn't match 'example.com'

バージョン3.2の新機能。

バージョン3.3.3で変更：関数は RFC 6125 、セクション6.4.3に従い、複数のワイルドカードと一致しません（例： *.*.comまたは*a*.example.org）も、国際化ドメイン名（IDN）フラグメント内のワイルドカードもありません。 www*.xn--pthon-kva.orgなどのIDNAラベルは引き続きサポートされますが、x*.python.orgはxn--tda.python.orgと一致しなくなりました。

バージョン3.5で変更：証明書のsubjectAltNameフィールドに存在する場合のIPアドレスのマッチングがサポートされるようになりました。

バージョン3.7で変更：この関数はTLS接続には使用されなくなりました。 ホスト名の照合がOpenSSLによって実行されるようになりました。

ワイルドカードがそのセグメントの左端で唯一の文字である場合は、ワイルドカードを許可します。 www*.example.comのような部分的なワイルドカードはサポートされなくなりました。

バージョン3.7以降非推奨。

ssl.cert_time_to_seconds(cert_time)

"%b %d %H:%M:%S %Y %Z" strptime形式（Cロケール）の証明書からの「notBefore」または「notAfter」日付を表すcert_time文字列を指定して、エポックからの時間を秒単位で返します。

次に例を示します。

>>> import ssl
>>> timestamp = ssl.cert_time_to_seconds("Jan  5 09:34:43 2018 GMT")
>>> timestamp  
1515144883
>>> from datetime import datetime
>>> print(datetime.utcfromtimestamp(timestamp))  
2018-01-05 09:34:43

「notBefore」または「notAfter」の日付はGMT（ RFC 5280 ）を使用する必要があります。

バージョン3.5で変更：入力文字列の「GMT」タイムゾーンで指定されたUTC単位の時刻として入力時刻を解釈します。 以前はローカルタイムゾーンが使用されていました。 整数を返します（入力形式で秒の小数部はありません）

ssl.get_server_certificate(addr, ssl_version=PROTOCOL_TLS, ca_certs=None)

SSLで保護されたサーバーのアドレスaddrを（ hostname 、 port-number ）ペアとして指定すると、サーバーの証明書をフェッチし、それをPEMとして返します。 -エンコードされた文字列。 ssl_versionが指定されている場合、そのバージョンのSSLプロトコルを使用してサーバーへの接続を試みます。 ca_certsを指定する場合は、 SSLContext.wrap_socket（）の同じパラメーターに使用されるのと同じ形式のルート証明書のリストを含むファイルである必要があります。 呼び出しは、そのルート証明書のセットに対してサーバー証明書の検証を試み、検証の試みが失敗した場合は失敗します。

バージョン3.3で変更：この関数はIPv6互換になりました。

バージョン3.5での変更：デフォルトの ssl_version が PROTOCOL_SSLv3 から PROTOCOL_TLS に変更され、最新のサーバーとの互換性が最大になりました。

ssl.DER_cert_to_PEM_cert(DER_cert_bytes)
証明書をDERでエンコードされたバイトのブロブとして指定すると、同じ証明書のPEMでエンコードされた文字列バージョンが返されます。
ssl.PEM_cert_to_DER_cert(PEM_cert_string)
証明書をASCIIPEM文字列として指定すると、同じ証明書に対してDERでエンコードされたバイトシーケンスを返します。
ssl.get_default_verify_paths()

OpenSSLのデフォルトのcafileおよびcapathへのパスを持つ名前付きタプルを返します。 パスは、 SSLContext.set_default_verify_paths（）で使用されるものと同じです。 戻り値は、名前付きタプル DefaultVerifyPathsです。

  • cafile -cafileへの解決済みパス、またはファイルが存在しない場合はNone、

  • capath -capathへのパスを解決しました。ディレクトリが存在しない場合は、Noneを使用します。

  • openssl_cafile_env -cafileを指すOpenSSLの環境キー、

  • openssl_cafile -cafileへのハードコードされたパス、

  • openssl_capath_env -capathを指すOpenSSLの環境キー、

  • openssl_capath -capathディレクトリへのハードコードされたパス

バージョン3.4の新機能。

ssl.enum_certificates(store_name)

Windowsのシステム証明書ストアから証明書を取得します。 store_name は、CA、ROOT、またはMYのいずれかです。 Windowsは、追加の証明書ストアも提供する場合があります。

この関数は、（cert_bytes、encoding_type、trust）タプルのリストを返します。 encoding_typeは、cert_bytesのエンコーディングを指定します。 X.509ASN.1データの場合はx509_asn、PKCS＃7ASN.1データの場合はpkcs_7_asnのいずれかです。 信頼は、証明書の目的をOIDのセットとして指定するか、証明書がすべての目的で信頼できる場合は正確にTrueを指定します。

例：

>>> ssl.enum_certificates("CA")
[(b'data...', 'x509_asn', {'1.3.6.1.5.5.7.3.1', '1.3.6.1.5.5.7.3.2'}),
 (b'data...', 'x509_asn', True)]

バージョン3.4の新機能。

ssl.enum_crls(store_name)

Windowsのシステム証明書ストアからCRLを取得します。 store_name は、CA、ROOT、またはMYのいずれかです。 Windowsは、追加の証明書ストアも提供する場合があります。

この関数は、（cert_bytes、encoding_type、trust）タプルのリストを返します。 encoding_typeは、cert_bytesのエンコーディングを指定します。 X.509ASN.1データの場合はx509_asn、PKCS＃7ASN.1データの場合はpkcs_7_asnのいずれかです。

バージョン3.4の新機能。

ssl.wrap_socket(sock, keyfile=None, certfile=None, server_side=False, cert_reqs=CERT_NONE, ssl_version=PROTOCOL_TLS, ca_certs=None, do_handshake_on_connect=True, suppress_ragged_eofs=True, ciphers=None)

socket.socket のインスタンスsockを取得し、 socket.socket のサブタイプである ssl.SSLSocket のインスタンスを返します。 SSLコンテキストの基礎となるソケット。 sockは SOCK_STREAM ソケットである必要があります。 他のソケットタイプはサポートされていません。

内部的に、関数はプロトコル ssl_version および SSLContext.options が cert_reqs に設定された SSLContext を作成します。 パラメータ keyfile 、 certfile 、 ca_certs 、または ciphers が設定されている場合、値は SSLContext.load_cert_chain（）に渡されます。 、 SSLContext.load_verify_locations（）、および SSLContext.set_ciphers（）。

引数 server_side 、 do_handshake_on_connect 、および suppress_ragged_eofs は、 SSLContext.wrap_socket（）と同じ意味です。

バージョン3.7以降非推奨： Python 3.2および2.7.9以降、 wrap_socket（）の代わりに SSLContext.wrap_socket（）を使用することをお勧めします。 トップレベルの機能は制限されており、サーバー名の表示やホスト名の一致なしに安全でないクライアントソケットを作成します。


定数

すべての定数が enum.IntEnum または enum.IntFlag コレクションになりました。

バージョン3.6の新機能。


ssl.CERT_NONE

SSLContext.verify_mode の可能な値、または wrap_socket（）へのcert_reqsパラメーター。 PROTOCOL_TLS_CLIENT を除いて、これはデフォルトのモードです。 クライアント側のソケットでは、ほぼすべての証明書が受け入れられます。 信頼できない証明書や期限切れの証明書などの検証エラーは無視され、TLS / SSLハンドシェイクを中止しません。

サーバーモードでは、クライアントから証明書が要求されないため、クライアントはクライアント証明書認証のために証明書を送信しません。

以下のセキュリティに関する考慮事項の説明を参照してください。

ssl.CERT_OPTIONAL

SSLContext.verify_mode の可能な値、または wrap_socket（）へのcert_reqsパラメーター。 クライアントモードでは、 CERT_OPTIONAL は CERT_REQUIRED と同じ意味です。 代わりに、クライアント側のソケットには CERT_REQUIRED を使用することをお勧めします。

サーバーモードでは、クライアント証明書要求がクライアントに送信されます。 クライアントは、TLSクライアント証明書認証を実行するために、要求を無視するか、証明書を送信することができます。 クライアントが証明書の送信を選択した場合、それは検証されます。 検証エラーが発生すると、TLSハンドシェイクはただちに中止されます。

この設定を使用するには、有効なCA証明書のセットを SSLContext.load_verify_locations（）に渡すか、ca_certsパラメーターの値として wrap_socket（）に渡す必要があります。 ]。

ssl.CERT_REQUIRED

SSLContext.verify_mode の可能な値、または wrap_socket（）へのcert_reqsパラメーター。 このモードでは、ソケット接続の反対側から証明書が必要です。 SSLError は、証明書が提供されていない場合、またはその検証が失敗した場合に発生します。 このモードは、ホスト名と一致しないため、クライアントモードで証明書を検証するには十分ではありません。 証明書の信頼性を検証するには、 check_hostname も有効にする必要があります。 PROTOCOL_TLS_CLIENT は、 CERT_REQUIRED を使用し、デフォルトで check_hostname を有効にします。

サーバーソケットでは、このモードは必須のTLSクライアント証明書認証を提供します。 クライアント証明書要求がクライアントに送信され、クライアントは有効で信頼できる証明書を提供する必要があります。

この設定を使用するには、有効なCA証明書のセットを SSLContext.load_verify_locations（）に渡すか、ca_certsパラメーターの値として wrap_socket（）に渡す必要があります。 ]。

class ssl.VerifyMode

enum.IntEnum CERT_ *定数のコレクション。

バージョン3.6の新機能。

ssl.VERIFY_DEFAULT

SSLContext.verify_flags の可能な値。 このモードでは、証明書失効リスト（CRL）はチェックされません。 デフォルトでは、OpenSSLはCRLを必要とせず検証もしません。

バージョン3.4の新機能。

ssl.VERIFY_CRL_CHECK_LEAF

SSLContext.verify_flags の可能な値。 このモードでは、ピア証明書のみがチェックされ、中間CA証明書はチェックされません。 このモードには、ピア証明書の発行者（その直接の祖先CA）によって署名された有効なCRLが必要です。 SSLContext.load_verify_locations で適切なCRLがロードされていない場合、検証は失敗します。

バージョン3.4の新機能。

ssl.VERIFY_CRL_CHECK_CHAIN

SSLContext.verify_flags の可能な値。 このモードでは、ピア証明書チェーン内のすべての証明書のCRLがチェックされます。

バージョン3.4の新機能。

ssl.VERIFY_X509_STRICT

SSLContext.verify_flags の可能な値は、壊れたX.509証明書の回避策を無効にします。

バージョン3.4の新機能。

ssl.VERIFY_X509_TRUSTED_FIRST

SSLContext.verify_flags の可能な値。 証明書を検証するための信頼チェーンを構築するときに、信頼できる証明書を優先するようにOpenSSLに指示します。 このフラグはデフォルトで有効になっています。

バージョン3.4.4の新機能。

class ssl.VerifyFlags

enum.IntFlag VERIFY_ *定数のコレクション。

バージョン3.6の新機能。

ssl.PROTOCOL_TLS

クライアントとサーバーの両方がサポートする最高のプロトコルバージョンを選択します。 名前にもかかわらず、このオプションは「SSL」プロトコルと「TLS」プロトコルの両方を選択できます。

バージョン3.6の新機能。

ssl.PROTOCOL_TLS_CLIENT

PROTOCOL_TLS のような最高のプロトコルバージョンを自動ネゴシエートしますが、クライアント側の SSLSocket 接続のみをサポートします。 このプロトコルは、デフォルトで CERT_REQUIRED および check_hostname を有効にします。

バージョン3.6の新機能。

ssl.PROTOCOL_TLS_SERVER

PROTOCOL_TLS のような最高のプロトコルバージョンを自動ネゴシエートしますが、サーバー側の SSLSocket 接続のみをサポートします。

バージョン3.6の新機能。

ssl.PROTOCOL_SSLv23

PROTOCOL_TLS のエイリアス。

バージョン3.6以降非推奨：代わりに PROTOCOL_TLS を使用してください。

ssl.PROTOCOL_SSLv2

チャネル暗号化プロトコルとしてSSLバージョン2を選択します。

OpenSSLがOPENSSL_NO_SSL2フラグを使用してコンパイルされている場合、このプロトコルは使用できません。

警告

SSLバージョン2は安全ではありません。 その使用は強くお勧めしません。

バージョン3.6以降非推奨： OpenSSLはSSLv2のサポートを削除しました。

ssl.PROTOCOL_SSLv3

チャネル暗号化プロトコルとしてSSLバージョン3を選択します。

OpenSSLがOPENSSL_NO_SSLv3フラグを使用してコンパイルされている場合、このプロトコルは使用できません。

警告

SSLバージョン3は安全ではありません。 その使用は強くお勧めしません。

バージョン3.6以降非推奨： OpenSSLはすべてのバージョン固有のプロトコルを非推奨にしました。 代わりに、 OP_NO_SSLv3 のようなフラグを持つデフォルトのプロトコル PROTOCOL_TLS を使用してください。

ssl.PROTOCOL_TLSv1

チャネル暗号化プロトコルとしてTLSバージョン1.0を選択します。

バージョン3.6以降非推奨： OpenSSLはすべてのバージョン固有のプロトコルを非推奨にしました。 代わりに、 OP_NO_SSLv3 のようなフラグを持つデフォルトのプロトコル PROTOCOL_TLS を使用してください。

ssl.PROTOCOL_TLSv1_1

チャネル暗号化プロトコルとしてTLSバージョン1.1を選択します。 opensslバージョン1.0.1以降でのみ使用できます。

バージョン3.4の新機能。

バージョン3.6以降非推奨： OpenSSLはすべてのバージョン固有のプロトコルを非推奨にしました。 代わりに、 OP_NO_SSLv3 のようなフラグを持つデフォルトのプロトコル PROTOCOL_TLS を使用してください。

ssl.PROTOCOL_TLSv1_2

チャネル暗号化プロトコルとしてTLSバージョン1.2を選択します。 これは最新バージョンであり、双方がそれを話すことができれば、おそらく最大限の保護のための最良の選択です。 opensslバージョン1.0.1以降でのみ使用できます。

バージョン3.4の新機能。

バージョン3.6以降非推奨： OpenSSLはすべてのバージョン固有のプロトコルを非推奨にしました。 代わりに、 OP_NO_SSLv3 のようなフラグを持つデフォルトのプロトコル PROTOCOL_TLS を使用してください。

ssl.OP_ALL

他のSSL実装に存在するさまざまなバグの回避策を有効にします。 このオプションはデフォルトで設定されています。 OpenSSLのSSL_OP_ALL定数と同じフラグを設定する必要はありません。

バージョン3.2の新機能。

ssl.OP_NO_SSLv2

SSLv2接続を防止します。 このオプションは、 PROTOCOL_TLS と組み合わせた場合にのみ適用できます。 これにより、ピアがプロトコルバージョンとしてSSLv2を選択できなくなります。

バージョン3.2の新機能。

バージョン3.6以降非推奨： SSLv2は非推奨

ssl.OP_NO_SSLv3

SSLv3接続を防止します。 このオプションは、 PROTOCOL_TLS と組み合わせた場合にのみ適用できます。 これにより、ピアがプロトコルバージョンとしてSSLv3を選択できなくなります。

バージョン3.2の新機能。

バージョン3.6以降非推奨： SSLv3は非推奨

ssl.OP_NO_TLSv1

TLSv1接続を防止します。 このオプションは、 PROTOCOL_TLS と組み合わせた場合にのみ適用できます。 これにより、ピアがプロトコルバージョンとしてTLSv1を選択できなくなります。

バージョン3.2の新機能。

バージョン3.7以降非推奨：このオプションはOpenSSL 1.1.0以降非推奨になりました。代わりに、新しい SSLContext.minimum_version および SSLContext.maximum_version を使用してください。

ssl.OP_NO_TLSv1_1

TLSv1.1接続を防止します。 このオプションは、 PROTOCOL_TLS と組み合わせた場合にのみ適用できます。 これにより、ピアがプロトコルバージョンとしてTLSv1.1を選択できなくなります。 opensslバージョン1.0.1以降でのみ使用できます。

バージョン3.4の新機能。

バージョン3.7以降非推奨：このオプションはOpenSSL1.1.0以降非推奨になりました。

ssl.OP_NO_TLSv1_2

TLSv1.2接続を防止します。 このオプションは、 PROTOCOL_TLS と組み合わせた場合にのみ適用できます。 これにより、ピアがプロトコルバージョンとしてTLSv1.2を選択できなくなります。 opensslバージョン1.0.1以降でのみ使用できます。

バージョン3.4の新機能。

バージョン3.7以降非推奨：このオプションはOpenSSL1.1.0以降非推奨になりました。

ssl.OP_NO_TLSv1_3

TLSv1.3接続を防止します。 このオプションは、 PROTOCOL_TLS と組み合わせた場合にのみ適用できます。 これにより、ピアがプロトコルバージョンとしてTLSv1.3を選択できなくなります。 TLS 1.3は、OpenSSL1.1.1以降で使用できます。 Pythonが古いバージョンのOpenSSLに対してコンパイルされている場合、フラグはデフォルトで 0 になります。

バージョン3.7の新機能。

バージョン3.7以降非推奨：このオプションはOpenSSL1.1.0以降非推奨になりました。 OpenSSL 1.0.2との下位互換性のために、2.7.15、3.6.3、および3.7.0に追加されました。

ssl.OP_NO_RENEGOTIATION

TLSv1.2以前ではすべての再ネゴシエーションを無効にします。 HelloRequestメッセージを送信せず、ClientHelloを介した再ネゴシエーション要求を無視します。

このオプションは、OpenSSL1.1.0h以降でのみ使用できます。

バージョン3.7の新機能。

ssl.OP_CIPHER_SERVER_PREFERENCE

クライアントではなく、サーバーの暗号順序設定を使用します。 このオプションは、クライアントソケットとSSLv2サーバーソケットには影響しません。

バージョン3.3の新機能。

ssl.OP_SINGLE_DH_USE

個別のSSLセッションで同じDHキーを再利用できないようにします。 これにより、Forward Secrecyが向上しますが、より多くの計算リソースが必要になります。 このオプションは、サーバーソケットにのみ適用されます。

バージョン3.3の新機能。

ssl.OP_SINGLE_ECDH_USE

個別のSSLセッションで同じECDHキーを再利用できないようにします。 これにより、Forward Secrecyが向上しますが、より多くの計算リソースが必要になります。 このオプションは、サーバーソケットにのみ適用されます。

バージョン3.3の新機能。

ssl.OP_ENABLE_MIDDLEBOX_COMPAT

TLS1.3ハンドシェイクでダミーのChangeCipher Spec（CCS）メッセージを送信して、TLS1.3接続をTLS1.2接続のように見せます。

このオプションは、OpenSSL1.1.1以降でのみ使用できます。

バージョン3.8の新機能。

ssl.OP_NO_COMPRESSION

SSLチャネルの圧縮を無効にします。 これは、アプリケーションプロトコルが独自の圧縮スキームをサポートしている場合に役立ちます。

このオプションは、OpenSSL1.0.0以降でのみ使用できます。

バージョン3.3の新機能。

class ssl.Options
enum.IntFlag OP_ *定数のコレクション。
ssl.OP_NO_TICKET

クライアント側がセッションチケットを要求しないようにします。

バージョン3.6の新機能。

ssl.OP_IGNORE_UNEXPECTED_EOF

TLS接続の予期しないシャットダウンを無視します。

このオプションは、OpenSSL3.0.0以降でのみ使用できます。

バージョン3.10の新機能。

ssl.HAS_ALPN

RFC 7301 で説明されているように、OpenSSLライブラリに Application-Layer Protocol Negotiation TLS拡張のサポートが組み込まれているかどうか。

バージョン3.5の新機能。

ssl.HAS_NEVER_CHECK_COMMON_NAME

OpenSSLライブラリにサブジェクトの共通名をチェックしないサポートが組み込まれているかどうか、および SSLContext.hostname_checks_common_name は書き込み可能です。

バージョン3.7の新機能。

ssl.HAS_ECDH

OpenSSLライブラリに、楕円曲線ベースのDiffie-Hellman鍵交換のサポートが組み込まれているかどうか。 これは、ディストリビューターによって機能が明示的に無効にされていない限り、当てはまるはずです。

バージョン3.3の新機能。

ssl.HAS_SNI

OpenSSLライブラリに Server Name Indication 拡張機能（ RFC 6066 で定義されている）のサポートが組み込まれているかどうか。

バージョン3.2の新機能。

ssl.HAS_NPN

アプリケーション層プロトコルネゴシエーションで説明されているように、OpenSSLライブラリに次のプロトコルネゴシエーションのサポートが組み込まれているかどうか。 trueの場合、 SSLContext.set_npn_protocols（）メソッドを使用して、サポートするプロトコルをアドバタイズできます。

バージョン3.3の新機能。

ssl.HAS_SSLv2

OpenSSLライブラリにSSL2.0プロトコルのサポートが組み込まれているかどうか。

バージョン3.7の新機能。

ssl.HAS_SSLv3

OpenSSLライブラリにSSL3.0プロトコルのサポートが組み込まれているかどうか。

バージョン3.7の新機能。

ssl.HAS_TLSv1

OpenSSLライブラリにTLS1.0プロトコルのサポートが組み込まれているかどうか。

バージョン3.7の新機能。

ssl.HAS_TLSv1_1

OpenSSLライブラリにTLS1.1プロトコルのサポートが組み込まれているかどうか。

バージョン3.7の新機能。

ssl.HAS_TLSv1_2

OpenSSLライブラリにTLS1.2プロトコルのサポートが組み込まれているかどうか。

バージョン3.7の新機能。

ssl.HAS_TLSv1_3

OpenSSLライブラリにTLS1.3プロトコルのサポートが組み込まれているかどうか。

バージョン3.7の新機能。

ssl.CHANNEL_BINDING_TYPES

サポートされているTLSチャネルバインディングタイプのリスト。 このリストの文字列は、 SSLSocket.get_channel_binding（）への引数として使用できます。

バージョン3.3の新機能。

ssl.OPENSSL_VERSION

インタプリタによってロードされたOpenSSLライブラリのバージョン文字列：

>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2k  26 Jan 2017'

バージョン3.2の新機能。

ssl.OPENSSL_VERSION_INFO

OpenSSLライブラリに関するバージョン情報を表す5つの整数のタプル：

>>> ssl.OPENSSL_VERSION_INFO
(1, 0, 2, 11, 15)

バージョン3.2の新機能。

ssl.OPENSSL_VERSION_NUMBER

単一の整数としてのOpenSSLライブラリの生のバージョン番号：

>>> ssl.OPENSSL_VERSION_NUMBER
268443839
>>> hex(ssl.OPENSSL_VERSION_NUMBER)
'0x100020bf'

バージョン3.2の新機能。

ssl.ALERT_DESCRIPTION_HANDSHAKE_FAILURE
ssl.ALERT_DESCRIPTION_INTERNAL_ERROR
ALERT_DESCRIPTION_*

RFC 5246 などからのアラートの説明。 IANA TLS Alert Registry には、このリストと、その意味が定義されているRFCへの参照が含まれています。

SSLContext.set_servername_callback（）のコールバック関数の戻り値として使用されます。

バージョン3.4の新機能。

class ssl.AlertDescription

enum.IntEnum ALERT_DESCRIPTION_ *定数のコレクション。

バージョン3.6の新機能。

Purpose.SERVER_AUTH

create_default_context（）および SSLContext.load_default_certs（）のオプション。 この値は、コンテキストを使用してWebサーバーを認証できることを示します（したがって、コンテキストはクライアント側のソケットを作成するために使用されます）。

バージョン3.4の新機能。

Purpose.CLIENT_AUTH

create_default_context（）および SSLContext.load_default_certs（）のオプション。 この値は、コンテキストを使用してWebクライアントを認証できることを示します（したがって、サーバー側のソケットを作成するために使用されます）。

バージョン3.4の新機能。

class ssl.SSLErrorNumber

enum.IntEnum SSL_ERROR_ *定数のコレクション。

バージョン3.6の新機能。

class ssl.TLSVersion

enum.IntEnum SSLContext.maximum_version および SSLContext.minimum_version のSSLおよびTLSバージョンのコレクション。

バージョン3.7の新機能。

TLSVersion.MINIMUM_SUPPORTED
TLSVersion.MAXIMUM_SUPPORTED
サポートされているSSLまたはTLSの最小または最大バージョン。 これらは魔法の定数です。 それらの値は、利用可能な最低および最高のTLS / SSLバージョンを反映していません。
TLSVersion.SSLv3
TLSVersion.TLSv1
TLSVersion.TLSv1_1
TLSVersion.TLSv1_2
TLSVersion.TLSv1_3
SSL3.0からTLS1.3。


SSLソケット

class ssl.SSLSocket(socket.socket)

SSLソケットは、 Socket Objects の次のメソッドを提供します。

ただし、SSL（およびTLS）プロトコルにはTCPの上に独自のフレーミングがあるため、SSLソケットの抽象化は、特定の点で、通常のOSレベルのソケットの仕様とは異なる可能性があります。 特に非ブロッキングソケットに関する注記を参照してください。

SSLSocket のインスタンスは、 SSLContext.wrap_socket（）メソッドを使用して作成する必要があります。

バージョン3.5で変更： sendfile()メソッドが追加されました。

バージョン3.5で変更： shutdown()は、バイトが送受信されるたびにソケットタイムアウトをリセットしません。 ソケットのタイムアウトは、シャットダウンの最大合計時間になりました。

バージョン3.6以降非推奨： SSLSocket インスタンスを直接作成することは非推奨です。 SSLContext.wrap_socket（）を使用してソケットをラップします。

バージョン3.7で変更： SSLSocket インスタンスは、 wrap_socket（）で作成する必要があります。 以前のバージョンでは、インスタンスを直接作成することが可能でした。 これは文書化されておらず、公式にサポートされていません。

SSLソケットには、次の追加のメソッドと属性もあります。

SSLSocket.read(len=1024, buffer=None)

SSLソケットから最大 len バイトのデータを読み取り、結果をbytesインスタンスとして返します。 buffer が指定されている場合は、代わりにバッファに読み込み、読み取ったバイト数を返します。

ソケットが non-blocking であり、読み取りがブロックされる場合は、 SSLWantReadError または SSLWantWriteError を発生させます。

再ネゴシエーションが可能な場合はいつでも、 read（）を呼び出すと書き込み操作が発生する可能性があります。

バージョン3.5で変更：バイトが送受信されるたびにソケットタイムアウトがリセットされなくなりました。 ソケットのタイムアウトは、最大 len バイトを読み取るための最大合計期間になりました。

バージョン3.6以降非推奨： read（）の代わりにrecv()を使用してください。

SSLSocket.write(buf)

buf をSSLソケットに書き込み、書き込まれたバイト数を返します。 buf 引数は、バッファインターフェイスをサポートするオブジェクトである必要があります。

ソケットが non-blocking であり、書き込みがブロックされる場合は、 SSLWantReadError または SSLWantWriteError を発生させます。

再ネゴシエーションが可能な場合はいつでも、 write（）を呼び出すと読み取り操作が発生する可能性があります。

バージョン3.5で変更：バイトが送受信されるたびにソケットタイムアウトがリセットされなくなりました。 ソケットのタイムアウトは、 buf を書き込むための最大合計期間になりました。

バージョン3.6以降非推奨： write（）の代わりにsend()を使用してください。

ノート

read（）および write（）メソッドは、暗号化されていないアプリケーションレベルのデータを読み書きし、暗号化されたワイヤーレベルのデータに復号化/暗号化する低レベルのメソッドです。 これらの方法には、アクティブなSSL接続が必要です。 ハンドシェイクが完了し、 SSLSocket.unwrap（）が呼び出されませんでした。

通常、これらのメソッドの代わりに、 recv（）や send（）などのソケットAPIメソッドを使用する必要があります。


SSLSocket.do_handshake()

SSLセットアップハンドシェイクを実行します。

バージョン3.4で変更：ソケットの context の check_hostname 属性がtrueの場合、ハンドシェイクメソッドは match_hostname（）も実行します。

バージョン3.5で変更：バイトが送受信されるたびにソケットタイムアウトがリセットされなくなりました。 ソケットのタイムアウトは、ハンドシェイクの最大合計時間になりました。

バージョン3.7で変更：ホスト名またはIPアドレスは、ハンドシェイク中にOpenSSLによって照合されます。 関数 match_hostname（）は使用されなくなりました。 OpenSSLがホスト名またはIPアドレスを拒否した場合、ハンドシェイクは早期に中止され、TLSアラートメッセージがピアに送信されます。

SSLSocket.getpeercert(binary_form=False)

接続のもう一方の端にピアの証明書がない場合は、Noneを返します。 SSLハンドシェイクがまだ実行されていない場合は、 ValueError を発生させます。

binary_formパラメーターが False であり、証明書がピアから受信された場合、このメソッドは dict インスタンスを返します。 証明書が検証されなかった場合、dictは空です。 証明書が検証された場合、subject（証明書が発行されたプリンシパル）とissuer（証明書を発行したプリンシパル）など、いくつかのキーを含むdictが返されます。 証明書に Subject Alternative Name 拡張子のインスタンスが含まれている場合（ RFC 3280 を参照）、subjectAltNameキーもあります。辞書。

subjectフィールドとissuerフィールドは、それぞれのフィールドの証明書のデータ構造で指定された相対識別名（RDN）のシーケンスを含むタプルであり、各RDNは名前と値のペアのシーケンスです。 これが実際の例です：

{'issuer': ((('countryName', 'IL'),),
            (('organizationName', 'StartCom Ltd.'),),
            (('organizationalUnitName',
              'Secure Digital Certificate Signing'),),
            (('commonName',
              'StartCom Class 2 Primary Intermediate Server CA'),)),
 'notAfter': 'Nov 22 08:15:19 2013 GMT',
 'notBefore': 'Nov 21 03:09:52 2011 GMT',
 'serialNumber': '95F0',
 'subject': ((('description', '571208-SLe257oHY9fVQ07Z'),),
             (('countryName', 'US'),),
             (('stateOrProvinceName', 'California'),),
             (('localityName', 'San Francisco'),),
             (('organizationName', 'Electronic Frontier Foundation, Inc.'),),
             (('commonName', '*.eff.org'),),
             (('emailAddress', '[email protected]'),)),
 'subjectAltName': (('DNS', '*.eff.org'), ('DNS', 'eff.org')),
 'version': 3}

ノート

特定のサービスの証明書を検証するには、 match_hostname（）関数を使用できます。

binary_formパラメーターが True であり、証明書が提供された場合、このメソッドは、証明書全体のDERエンコード形式をバイトシーケンスとして返すか、 None を返します。ピアが証明書を提供しなかった場合。 ピアが証明書を提供するかどうかは、SSLソケットの役割によって異なります。

  • クライアントSSLソケットの場合、検証が必要かどうかに関係なく、サーバーは常に証明書を提供します。

  • サーバーSSLソケットの場合、クライアントはサーバーから要求された場合にのみ証明書を提供します。 したがって、 CERT_OPTIONAL または CERT_REQUIRED ではなく CERT_NONE を使用した場合、 getpeercert（）は None を返します。

バージョン3.2で変更：返される辞書には、issuerやnotBeforeなどの追加アイテムが含まれています。

バージョン3.4で変更：ハンドシェイクが行われない場合、 ValueError が発生します。 返されるディクショナリには、crlDistributionPoints、caIssuers、OCSP URIなどの追加のX509v3拡張アイテムが含まれています。

バージョン3.8.1で変更： IPv6アドレス文字列の末尾に改行がなくなりました。

SSLSocket.cipher()
使用されている暗号の名前、その使用を定義するSSLプロトコルのバージョン、および使用されている秘密ビットの数を含む3つの値のタプルを返します。 接続が確立されていない場合は、Noneを返します。
SSLSocket.shared_ciphers()

ハンドシェイク中にクライアントによって共有された暗号のリストを返します。 返されるリストの各エントリは、暗号の名前、その使用を定義するSSLプロトコルのバージョン、および暗号が使用するシークレットビットの数を含む3つの値のタプルです。 shared_ciphers（）は、接続が確立されていない場合、またはソケットがクライアントソケットである場合、Noneを返します。

バージョン3.5の新機能。

SSLSocket.compression()

文字列として使用されている圧縮アルゴリズムを返します。接続が圧縮されていない場合はNoneを返します。

高レベルのプロトコルが独自の圧縮メカニズムをサポートしている場合は、 OP_NO_COMPRESSION を使用してSSLレベルの圧縮を無効にすることができます。

バージョン3.3の新機能。

SSLSocket.get_channel_binding(cb_type='tls-unique')

現在の接続のチャネルバインディングデータをbytesオブジェクトとして取得します。 接続されていない場合、またはハンドシェイクが完了していない場合は、Noneを返します。

cb_type パラメーターを使用すると、目的のチャネルバインディングタイプを選択できます。 有効なチャネルバインディングタイプは、 CHANNEL_BINDING_TYPES リストにリストされています。 現在、 RFC 5929 で定義されている「tls-unique」チャネルバインディングのみがサポートされています。 サポートされていないチャネルバインディングタイプが要求された場合、 ValueError が発生します。

バージョン3.3の新機能。

SSLSocket.selected_alpn_protocol()

TLSハンドシェイク中に選択されたプロトコルを返します。 SSLContext.set_alpn_protocols（）が呼び出されなかった場合、相手がALPNをサポートしていない場合、このソケットがクライアントの提案されたプロトコルのいずれもサポートしていない場合、またはハンドシェイクがまだ発生していない場合、Noneが返されます。

バージョン3.5の新機能。

SSLSocket.selected_npn_protocol()

TLS / SSLハンドシェイク中に選択された高レベルのプロトコルを返します。 SSLContext.set_npn_protocols（）が呼び出されなかった場合、相手がNPNをサポートしていない場合、またはハンドシェイクがまだ発生していない場合は、Noneが返されます。

バージョン3.3の新機能。

SSLSocket.unwrap()
SSLシャットダウンハンドシェイクを実行します。これにより、基になるソケットからTLSレイヤーが削除され、基になるソケットオブジェクトが返されます。 これは、接続を介した暗号化された操作から暗号化されていない操作に移行するために使用できます。 返されたソケットは、元のソケットではなく、接続の反対側とのさらなる通信に常に使用する必要があります。
SSLSocket.verify_client_post_handshake()

TLS 1.3クライアントからハンドシェイク後認証（PHA）を要求します。 PHAは、サーバー側ソケットからのTLS 1.3接続に対してのみ開始できます。最初のTLSハンドシェイクの後、両側でPHAが有効になっている場合は、 SSLContext.post_handshake_auth を参照してください。

このメソッドは、証明書交換をすぐには実行しません。 サーバー側は、次の書き込みイベント中にCertificateRequestを送信し、クライアントが次の読み取りイベントで証明書で応答することを期待します。

前提条件が満たされていない場合（例： TLS 1.3ではなく、PHAが有効になっていない場合）、 SSLError が発生します。

ノート

OpenSSL1.1.1およびTLS1.3が有効になっている場合にのみ使用できます。 TLS 1.3がサポートされていない場合、このメソッドは NotImplementedError を発生させます。

バージョン3.8の新機能。

SSLSocket.version()

接続によってネゴシエートされた実際のSSLプロトコルバージョンを文字列として返すか、Noneは安全な接続が確立されていません。 この記事の執筆時点で、可能な戻り値には、"SSLv2"、"SSLv3"、"TLSv1"、"TLSv1.1"、および"TLSv1.2"が含まれます。 最近のOpenSSLバージョンでは、より多くの戻り値が定義される場合があります。

バージョン3.5の新機能。

SSLSocket.pending()
接続で保留中の、読み取りに使用可能な復号化済みのバイト数を返します。
SSLSocket.context

このSSLソケットが関連付けられている SSLContext オブジェクト。 非推奨の wrap_socket（）関数（ SSLContext.wrap_socket（）ではなく）を使用してSSLソケットが作成された場合、これはこのSSLソケット用に作成されたカスタムコンテキストオブジェクトです。

バージョン3.2の新機能。

SSLSocket.server_side

サーバー側ソケットの場合はTrue、クライアント側ソケットの場合はFalseのブール値。

バージョン3.2の新機能。

SSLSocket.server_hostname

サーバーのホスト名： str タイプ、またはサーバー側ソケットの場合はNone、コンストラクターでホスト名が指定されていない場合。

バージョン3.2の新機能。

バージョン3.7で変更：属性は常にASCIIテキストになりました。 server_hostnameが国際化ドメイン名（IDN）の場合、この属性はUラベル形式（"pythön.org"）ではなくAラベル形式（"xn--pythn-mua.org"）を格納するようになりました。

SSLSocket.session

このSSL接続の SSLSession 。 セッションは、TLSハンドシェイクが実行された後、クライアント側とサーバー側のソケットで使用できます。 クライアントソケットの場合、セッションを再利用するために do_handshake（）が呼び出される前にセッションを設定できます。

バージョン3.6の新機能。

SSLSocket.session_reused

バージョン3.6の新機能。


SSLコンテキスト

バージョン3.2の新機能。


SSLコンテキストは、SSL構成オプション、証明書、秘密鍵など、単一のSSL接続よりも長寿命のさまざまなデータを保持します。 また、同じクライアントからの繰り返し接続を高速化するために、サーバー側ソケットのSSLセッションのキャッシュを管理します。

class ssl.SSLContext(protocol=PROTOCOL_TLS)

新しいSSLコンテキストを作成します。 プロトコルを渡すことができます。これは、このモジュールで定義されているPROTOCOL_*定数の1つである必要があります。 このパラメーターは、使用するSSLプロトコルのバージョンを指定します。 通常、サーバーは特定のプロトコルバージョンを選択し、クライアントはサーバーの選択に適応する必要があります。 ほとんどのバージョンは、他のバージョンと相互運用できません。 指定しない場合、デフォルトは PROTOCOL_TLS です。 他のバージョンとの互換性が最も高くなります。

これは、クライアントのどのバージョン（下側）がサーバー内のどのバージョンに（上部に沿って）接続できるかを示す表です。

クライアント / サーバー

SSLv2

SSLv3

TLS 3

TLSv1

TLSv1.1

TLSv1.2

SSLv2

はい

いいえ

いいえ 1

いいえ

いいえ

いいえ

SSLv3

いいえ

はい

いいえ 2

いいえ

いいえ

いいえ

TLS （ SSLv23 ） 3

いいえ 1

いいえ 2

はい

はい

はい

はい

TLSv1

いいえ

いいえ

はい

はい

いいえ

いいえ

TLSv1.1

いいえ

いいえ

はい

いいえ

はい

いいえ

TLSv1.2

いいえ

いいえ

はい

いいえ

いいえ

はい


脚注

1（ 1 、 2 ）

SSLContext は、デフォルトで OP_NO_SSLv2 を使用してSSLv2を無効にします。

2（ 1 、 2 ）

SSLContext は、デフォルトで OP_NO_SSLv3 を使用してSSLv3を無効にします。

3（ 1 、 2 ）

TLS 1.3プロトコルは、OpenSSL> = 1.1.1の PROTOCOL_TLS で使用できます。 TLS1.3だけに専用のPROTOCOL定数はありません。

も参照してください

create_default_context（）を使用すると、 ssl モジュールで特定の目的のセキュリティ設定を選択できます。

バージョン3.6で変更：コンテキストは安全なデフォルト値で作成されます。 オプション OP_NO_COMPRESSION 、 OP_CIPHER_SERVER_PREFERENCE 、 OP_SINGLE_DH_USE 、 OP_SINGLE_ECDH_USE 、 OP_X167Xv2 ]）、および OP_NO_SSLv3 （ PROTOCOL_SSLv3 を除く）がデフォルトで設定されています。 最初の暗号スイートリストには、HIGH暗号のみが含まれ、NULL暗号は含まれず、MD5暗号は含まれません（ PROTOCOL_SSLv2 を除く）。

SSLContext オブジェクトには、次のメソッドと属性があります。

SSLContext.cert_store_stats()

ロードされたX.509証明書の数、CA証明書としてフラグが立てられたX.509証明書の数、および辞書としての証明書失効リストに関する統計を取得します。

1つのCA証明書と1つの他の証明書を持つコンテキストの例：

>>> context.cert_store_stats()
{'crl': 0, 'x509_ca': 1, 'x509': 2}

バージョン3.4の新機能。

SSLContext.load_cert_chain(certfile, keyfile=None, password=None)

秘密鍵と対応する証明書をロードします。 certfile 文字列は、証明書と、証明書の信頼性を確立するために必要な任意の数のCA証明書を含むPEM形式の単一ファイルへのパスである必要があります。 keyfile 文字列は、存在する場合、の秘密鍵を含むファイルを指している必要があります。 それ以外の場合、秘密鍵は certfile からも取得されます。 証明書が証明書ファイルに格納される方法の詳細については、証明書の説明を参照してください。

password 引数は、秘密鍵を復号化するためのパスワードを取得するために呼び出す関数である可能性があります。 秘密鍵が暗号化されており、パスワードが必要な場合にのみ呼び出されます。 引数なしで呼び出され、文字列、バイト、またはバイト配列を返す必要があります。 戻り値が文字列の場合、キーを復号化するために使用する前に、UTF-8としてエンコードされます。 または、文字列、バイト、またはバイト配列の値を password 引数として直接指定することもできます。 秘密鍵が暗号化されておらず、パスワードが不要な場合は無視されます。

password 引数が指定されておらず、パスワードが必要な場合は、OpenSSLの組み込みのパスワードプロンプトメカニズムを使用して、ユーザーにパスワードの入力をインタラクティブに要求します。

秘密鍵が証明書と一致しない場合、 SSLError が発生します。

バージョン3.3で変更：新しいオプションの引数パスワード。

SSLContext.load_default_certs(purpose=Purpose.SERVER_AUTH)

デフォルトの場所からデフォルトの「証明機関」（CA）証明書のセットをロードします。 Windowsでは、CAおよびROOTシステムストアからCA証明書をロードします。 他のシステムでは、 SSLContext.set_default_verify_paths（）を呼び出します。 将来的には、このメソッドは他の場所からもCA証明書をロードする可能性があります。

purpose フラグは、ロードされるCA証明書の種類を指定します。 デフォルト設定 Purpose.SERVER_AUTH は、TLS Webサーバー認証（クライアント側ソケット）に対してフラグが付けられ、信頼されている証明書をロードします。 Purpose.CLIENT_AUTH は、サーバー側でクライアント証明書を検証するためにCA証明書をロードします。

バージョン3.4の新機能。

SSLContext.load_verify_locations(cafile=None, capath=None, cadata=None)

verify_mode が CERT_NONE 以外の場合に、他のピアの証明書を検証するために使用される「認証局」（CA）証明書のセットをロードします。 cafile または capath の少なくとも1つを指定する必要があります。

このメソッドは、PEMまたはDER形式の証明書失効リスト（CRL）をロードすることもできます。 CRLを使用するには、 SSLContext.verify_flags を適切に構成する必要があります。

cafile 文字列は、存在する場合、PEM形式で連結されたCA証明書のファイルへのパスです。 このファイルに証明書を配置する方法の詳細については、証明書の説明を参照してください。

capath 文字列は、存在する場合、 OpenSSL固有のレイアウトに従って、PEM形式の複数のCA証明書を含むディレクトリへのパスです。

cadata オブジェクトは、存在する場合、1つ以上のPEMエンコード証明書のASCII文字列、またはDERエンコード証明書のバイトのようなオブジェクトのいずれかです。 capath と同様に、PEMでエンコードされた証明書の周りの余分な行は無視されますが、少なくとも1つの証明書が存在する必要があります。

バージョン3.4で変更：新しいオプションの引数 cadata

SSLContext.get_ca_certs(binary_form=False)

ロードされた「証明機関」（CA）証明書のリストを取得します。 binary_formパラメーターが False の場合、各リストエントリは SSLSocket.getpeercert（）の出力のようなdictです。 それ以外の場合、メソッドはDERでエンコードされた証明書のリストを返します。 返されるリストには、SSL接続によって証明書が要求およびロードされない限り、 capath からの証明書は含まれていません。

ノート

capathディレクトリ内の証明書は、少なくとも1回使用されていない限り、ロードされません。

バージョン3.4の新機能。

SSLContext.get_ciphers()

有効な暗号のリストを取得します。 このリストは、暗号の優先順位の順になっています。 SSLContext.set_ciphers（）を参照してください。

例：

>>> ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
>>> ctx.set_ciphers('ECDHE+AESGCM:!ECDSA')
>>> ctx.get_ciphers()  # OpenSSL 1.0.x
[{'alg_bits': 256,
  'description': 'ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  '
                 'Enc=AESGCM(256) Mac=AEAD',
  'id': 50380848,
  'name': 'ECDHE-RSA-AES256-GCM-SHA384',
  'protocol': 'TLSv1/SSLv3',
  'strength_bits': 256},
 {'alg_bits': 128,
  'description': 'ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  '
                 'Enc=AESGCM(128) Mac=AEAD',
  'id': 50380847,
  'name': 'ECDHE-RSA-AES128-GCM-SHA256',
  'protocol': 'TLSv1/SSLv3',
  'strength_bits': 128}]

OpenSSL 1.1以降では、暗号辞書に追加のフィールドが含まれています。

>>> ctx.get_ciphers()  # OpenSSL 1.1+
[{'aead': True,
  'alg_bits': 256,
  'auth': 'auth-rsa',
  'description': 'ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  '
                 'Enc=AESGCM(256) Mac=AEAD',
  'digest': None,
  'id': 50380848,
  'kea': 'kx-ecdhe',
  'name': 'ECDHE-RSA-AES256-GCM-SHA384',
  'protocol': 'TLSv1.2',
  'strength_bits': 256,
  'symmetric': 'aes-256-gcm'},
 {'aead': True,
  'alg_bits': 128,
  'auth': 'auth-rsa',
  'description': 'ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  '
                 'Enc=AESGCM(128) Mac=AEAD',
  'digest': None,
  'id': 50380847,
  'kea': 'kx-ecdhe',
  'name': 'ECDHE-RSA-AES128-GCM-SHA256',
  'protocol': 'TLSv1.2',
  'strength_bits': 128,
  'symmetric': 'aes-128-gcm'}]

バージョン3.6の新機能。

SSLContext.set_default_verify_paths()
OpenSSLライブラリの構築時に定義されたファイルシステムパスから、デフォルトの「認証局」（CA）証明書のセットをロードします。 残念ながら、このメソッドが成功したかどうかを知る簡単な方法はありません。証明書が見つからない場合でもエラーは返されません。 ただし、OpenSSLライブラリがオペレーティングシステムの一部として提供されている場合は、適切に構成されている可能性があります。
SSLContext.set_ciphers(ciphers)

このコンテキストで作成されたソケットに使用可能な暗号を設定します。 OpenSSL暗号リスト形式の文字列である必要があります。 暗号を選択できない場合（コンパイル時オプションまたは他の構成で指定されたすべての暗号の使用が禁止されているため）、 SSLError が発生します。

ノート

接続すると、SSLソケットの SSLSocket.cipher（）メソッドが現在選択されている暗号を提供します。

OpenSSL 1.1.1では、TLS1.3暗号スイートがデフォルトで有効になっています。 スイートは set_ciphers（）で無効にすることはできません。

SSLContext.set_alpn_protocols(protocols)

SSL / TLSハンドシェイク中にソケットがアドバタイズするプロトコルを指定します。 ['http/1.1', 'spdy/2']のように、優先順に並べられたASCII文字列のリストである必要があります。 プロトコルの選択はハンドシェイク中に行われ、 RFC 7301 に従って実行されます。 ハンドシェイクが成功すると、 SSLSocket.selected_alpn_protocol（）メソッドは合意されたプロトコルを返します。

HAS_ALPN がFalseの場合、このメソッドは NotImplementedError を発生させます。

OpenSSL 1.1.0から1.1.0eは、双方がALPNをサポートしているがプロトコルについて合意できない場合、ハンドシェイクを中止し、 SSLError を発生させます。 1.1.0f +は1.0.2のように動作し、 SSLSocket.selected_alpn_protocol（）はNoneを返します。

バージョン3.5の新機能。

SSLContext.set_npn_protocols(protocols)

SSL / TLSハンドシェイク中にソケットがアドバタイズするプロトコルを指定します。 ['http/1.1', 'spdy/2']のように、優先順に並べられた文字列のリストである必要があります。 プロトコルの選択はハンドシェイク中に行われ、アプリケーション層プロトコルネゴシエーションに従って実行されます。 ハンドシェイクが成功すると、 SSLSocket.selected_npn_protocol（）メソッドは合意されたプロトコルを返します。

HAS_NPN がFalseの場合、このメソッドは NotImplementedError を発生させます。

バージョン3.3の新機能。

SSLContext.sni_callback

TLSクライアントがサーバー名の指示を指定したときにSSL / TLSサーバーがTLSクライアントHelloハンドシェイクメッセージを受信した後に呼び出されるコールバック関数を登録します。 サーバー名表示メカニズムは、 RFC 6066 セクション3-サーバー名表示で指定されています。

SSLContextごとに設定できるコールバックは1つだけです。 sni_callback がNoneに設定されている場合、コールバックは無効になります。 後でこの関数を呼び出すと、以前に登録されたコールバックが無効になります。

コールバック関数は3つの引数で呼び出されます。 1つ目は ssl.SSLSocket で、2つ目はクライアントが通信しようとしているサーバー名を表す文字列です（TLS Client Helloにサーバーが含まれていない場合は、 None ）。名前）、3番目の引数は元の SSLContext です。 サーバー名の引数はテキストです。 国際化ドメイン名の場合、サーバー名はIDN Aラベル（"xn--pythn-mua.org"）です。

このコールバックの一般的な使用法は、 ssl.SSLSocket の SSLSocket.context 属性を、一致する証明書チェーンを表すタイプ SSLContext の新しいオブジェクトに変更することです。サーバー名。

TLS接続の初期のネゴシエーションフェーズのため、 SSLSocket.selected_alpn_protocol（）や SSLSocket.context のように限られたメソッドと属性のみが使用可能です。 SSLSocket.getpeercert（）、 SSLSocket.getpeercert（）、 SSLSocket.cipher（）およびSSLSocket.compress()メソッドでは、TLS接続が進行している必要がありますTLSクライアントHelloを超えているため、意味のある戻り値が含まれず、安全に呼び出すこともできません。

sni_callback 関数は、TLSネゴシエーションを続行できるように、Noneを返す必要があります。 TLS障害が必要な場合は、定数 ALERT_DESCRIPTION _ * を返すことができます。 他の戻り値は、 ALERT_DESCRIPTION_INTERNAL_ERROR でTLS致命的なエラーになります。

sni_callback 関数から例外が発生した場合、TLS接続は致命的なTLSアラートメッセージ ALERT_DESCRIPTION_HANDSHAKE_FAILURE で終了します。

このメソッドは、OpenSSLライブラリの構築時にOPENSSL_NO_TLSEXTが定義されている場合、 NotImplementedError を発生させます。

バージョン3.7の新機能。

SSLContext.set_servername_callback(server_name_callback)

これは、下位互換性のために保持されているレガシーAPIです。 可能であれば、代わりに sni_callback を使用する必要があります。 指定された server_name_callback は sni_callback に似ていますが、サーバーのホスト名がIDNでエンコードされた国際化ドメイン名の場合、 server_name_callback はデコードされたUラベルを受け取ります（ "pythön.org"）。

サーバー名にデコードエラーがある場合、TLS接続は ALERT_DESCRIPTION_INTERNAL_ERROR クライアントへの致命的なTLSアラートメッセージで終了します。

バージョン3.4の新機能。

SSLContext.load_dh_params(dhfile)

Diffie-Hellman（DH）鍵交換の鍵生成パラメーターをロードします。 DH鍵交換を使用すると、計算リソース（サーバーとクライアントの両方）を犠牲にして前方秘書が改善されます。 dhfile パラメーターは、PEM形式のDHパラメーターを含むファイルへのパスである必要があります。

この設定は、クライアントソケットには適用されません。 OP_SINGLE_DH_USE オプションを使用して、セキュリティをさらに向上させることもできます。

バージョン3.3の新機能。

SSLContext.set_ecdh_curve(curve_name)

楕円曲線ベースのDiffie-Hellman（ECDH）鍵交換の曲線名を設定します。 ECDHは、通常のDHよりも大幅に高速ですが、ほぼ間違いなく安全です。 curve_name パラメーターは、よく知られている楕円曲線を表す文字列である必要があります。たとえば、広くサポートされている曲線の場合はprime256v1です。

この設定は、クライアントソケットには適用されません。 OP_SINGLE_ECDH_USE オプションを使用して、セキュリティをさらに向上させることもできます。

HAS_ECDH がFalseの場合、このメソッドは使用できません。

バージョン3.3の新機能。

も参照してください

SSL / TLSとPerfectForward Secrecy

ヴィンセントベルナト。


SSLContext.wrap_socket(sock, server_side=False, do_handshake_on_connect=True, suppress_ragged_eofs=True, server_hostname=None, session=None)

既存のPythonソケット sock をラップし、 SSLContext.sslsocket_class （デフォルトは SSLSocket ）のインスタンスを返します。 返されるSSLソケットは、コンテキスト、その設定、および証明書に関連付けられています。 sock は SOCK_STREAM ソケットである必要があります。 他のソケットタイプはサポートされていません。

パラメータserver_sideは、このソケットからサーバー側またはクライアント側のどちらの動作が必要かを識別するブール値です。

クライアント側のソケットの場合、コンテキストの構築は怠惰です。 基になるソケットがまだ接続されていない場合、コンテキストの構築は、ソケットでconnect()が呼び出された後に実行されます。 サーバー側ソケットの場合、ソケットにリモートピアがない場合、それはリスニングソケットであると見なされ、サーバー側SSLラッピングはaccept()メソッドを介して受け入れられたクライアント接続で自動的に実行されます。 このメソッドは SSLError を発生させる可能性があります。

クライアント接続では、オプションのパラメーター server_hostname は、接続先のサービスのホスト名を指定します。 これにより、HTTP仮想ホストとまったく同じように、単一のサーバーで複数のSSLベースのサービスを個別の証明書でホストできます。 server_hostname を指定すると、 server_side がtrueの場合、 ValueError が発生します。

パラメータdo_handshake_on_connectは、socket.connect()の実行後にSSLハンドシェイクを自動的に実行するか、またはアプリケーションプログラムが SSLSocket.do_handshake（）を呼び出してSSLハンドシェイクを明示的に呼び出すかを指定します。方法。 SSLSocket.do_handshake（）を呼び出すと、ハンドシェイクに関係するソケットI / Oのブロック動作をプログラムが明示的に制御できます。

パラメータsuppress_ragged_eofsは、SSLSocket.recv()メソッドが接続のもう一方の端から予期しないEOFを通知する方法を指定します。 True （デフォルト）として指定されている場合、基になるソケットから発生した予期しないEOFエラーに応答して、通常のEOF（空のバイトオブジェクト）を返します。 False の場合、例外が発生して呼び出し元に戻されます。

セッション。セッションを参照してください。

バージョン3.5で変更： OpenSSLにSNIがない場合でも、常にserver_hostnameの受け渡しを許可します。

バージョン3.6で変更： session 引数が追加されました。

バージョン3.7で変更：このメソッドは、ハードコードされた SSLSocket ではなく、 SSLContext.sslsocket_class のインスタンスを返します。

SSLContext.sslsocket_class

SSLContext.wrap_socket（）の戻りタイプは、デフォルトで SSLSocket です。 SSLSocket のカスタムサブクラスを返すために、クラスのインスタンスで属性をオーバーライドできます。

バージョン3.7の新機能。

SSLContext.wrap_bio(incoming, outgoing, server_side=False, server_hostname=None, session=None)

BIOオブジェクト着信および発信をラップし、 SSLContext.sslobject_class のインスタンスを返します（デフォルトは SSLObject ）。 SSLルーチンは、着信BIOから入力データを読み取り、発信BIOにデータを書き込みます。

server_side 、 server_hostname 、および session パラメーターは、 SSLContext.wrap_socket（）と同じ意味を持ちます。

バージョン3.6で変更： session 引数が追加されました。

バージョン3.7で変更：このメソッドは、ハードコードされた SSLObject ではなく、 SSLContext.sslobject_class のインスタンスを返します。

SSLContext.sslobject_class

SSLContext.wrap_bio（）の戻りタイプは、デフォルトで SSLObject です。 SSLObject のカスタムサブクラスを返すために、クラスのインスタンスで属性をオーバーライドできます。

バージョン3.7の新機能。

SSLContext.session_stats()

このコンテキストによって作成または管理されたSSLセッションに関する統計を取得します。 各情報の名前をそれらの数値にマップする辞書が返されます。 たとえば、コンテキストが作成されてからのセッションキャッシュでのヒットとミスの総数は次のとおりです。

>>> stats = context.session_stats()
>>> stats['hits'], stats['misses']
(0, 0)
SSLContext.check_hostname

SSLSocket.do_handshake（）のピア証明書のホスト名と一致するかどうか。 コンテキストの verify_mode を CERT_OPTIONAL または CERT_REQUIRED に設定し、 server_hostname を wrap_socket（）に渡す必要があります。ホスト名と一致させるため。 ホスト名チェックを有効にすると、 verify_mode が CERT_NONE から CERT_REQUIRED に自動的に設定されます。 ホスト名チェックが有効になっている限り、 CERT_NONE に戻すことはできません。 PROTOCOL_TLS_CLIENT プロトコルは、デフォルトでホスト名チェックを有効にします。 他のプロトコルでは、ホスト名チェックを明示的に有効にする必要があります。

例：

import socket, ssl

context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
context.verify_mode = ssl.CERT_REQUIRED
context.check_hostname = True
context.load_default_certs()

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = context.wrap_socket(s, server_hostname='www.verisign.com')
ssl_sock.connect(('www.verisign.com', 443))

バージョン3.4の新機能。

バージョン3.7での変更：ホスト名チェックが有効で、 verify_mode が CERT_NONE の場合、 verify_mode が自動的に CERT_REQUIRED に変更されるようになりました。 ]。 以前は、同じ操作が ValueError で失敗していました。

ノート

この機能には、OpenSSL0.9.8f以降が必要です。

SSLContext.keylog_filename

キーマテリアルが生成または受信されるたびに、TLSキーをキーログファイルに書き込みます。 キーログファイルは、デバッグのみを目的として設計されています。 ファイル形式はNSSによって指定され、Wiresharkなどの多くのトラフィックアナライザで使用されます。 ログファイルは追加専用モードで開かれます。 書き込みはスレッド間で同期されますが、プロセス間では同期されません。

バージョン3.8の新機能。

ノート

この機能には、OpenSSL1.1.1以降が必要です。

SSLContext.maximum_version

サポートされている最高のTLSバージョンを表す TLSVersion 列挙型メンバー。 値のデフォルトは TLSVersion.MAXIMUM_SUPPORTED です。 この属性は、 PROTOCOL_TLS 、 PROTOCOL_TLS_CLIENT 、および PROTOCOL_TLS_SERVER 以外のプロトコルでは読み取り専用です。

属性 maximum_version 、 minimum_version 、および SSLContext.options はすべて、サポートされているコンテキストのSSLおよびTLSバージョンに影響します。 実装は無効な組み合わせを防ぎません。 たとえば、 options の OP_NO_TLSv1_2 と maximum_version が TLSVersion.TLSv1_2 に設定されているコンテキストはTLS1.2接続を確立できません。

ノート

この属性は、sslモジュールがOpenSSL1.1.0g以降でコンパイルされていない限り使用できません。

バージョン3.7の新機能。

SSLContext.minimum_version

SSLContext.maximum_version と同様ですが、サポートされている最低バージョンまたは TLSVersion.MINIMUM_SUPPORTED です。

ノート

この属性は、sslモジュールがOpenSSL1.1.0g以降でコンパイルされていない限り使用できません。

バージョン3.7の新機能。

SSLContext.num_tickets

TLS_PROTOCOL_SERVERコンテキストのTLS1.3セッションチケットの数を制御します。 この設定は、TLS 1.0〜1.2接続には影響しません。

ノート

この属性は、sslモジュールがOpenSSL1.1.1以降でコンパイルされていない限り使用できません。

バージョン3.8の新機能。

SSLContext.options

このコンテキストで有効になっているSSLオプションのセットを表す整数。 デフォルト値は OP_ALL ですが、 OP_NO_SSLv2 などの他のオプションをORで指定することもできます。

ノート

0.9.8mより古いバージョンのOpenSSLでは、オプションを設定することのみが可能であり、それらをクリアすることはできません。 （対応するビットをリセットして）オプションをクリアしようとすると、 ValueError が発生します。

バージョン3.6で変更： SSLContext.options は Options フラグを返します。

>>> ssl.create_default_context().options  
<Options.OP_ALL|OP_NO_SSLv3|OP_NO_SSLv2|OP_NO_COMPRESSION: 2197947391>
SSLContext.post_handshake_auth

TLS1.3ハンドシェイク後のクライアント認証を有効にします。 ハンドシェイク後の認証はデフォルトで無効になっており、サーバーは最初のハンドシェイク中にのみTLSクライアント証明書を要求できます。 有効にすると、サーバーはハンドシェイク後いつでもTLSクライアント証明書を要求できます。

クライアント側のソケットで有効にすると、クライアントは、ハンドシェイク後の認証をサポートしていることをサーバーに通知します。

サーバー側のソケットで有効にする場合、 SSLContext.verify_mode も CERT_OPTIONAL または CERT_REQUIRED に設定する必要があります。 実際のクライアント証明書の交換は、 SSLSocket.verify_client_post_handshake（）が呼び出され、いくつかのI / Oが実行されるまで遅延されます。

ノート

OpenSSL1.1.1およびTLS1.3が有効になっている場合にのみ使用できます。 TLS 1.3がサポートされていない場合、プロパティ値はNoneであり、変更できません。

バージョン3.8の新機能。

SSLContext.protocol
コンテキストを構築するときに選択されたプロトコルバージョン。 この属性は読み取り専用です。
SSLContext.hostname_checks_common_name

check_hostname がフォールバックして、サブジェクト代替名の拡張子がない場合に証明書のサブジェクト共通名を確認するかどうか（デフォルト：true）。

ノート

OpenSSL1.1.0以降でのみ書き込み可能です。

バージョン3.7の新機能。

バージョン3.9.3で変更：バージョン1.1.1kより前のOpenSSLではフラグは効果がありませんでした。 Python 3.8.9、3.9.3、および3.10には、以前のバージョンの回避策が含まれています。

SSLContext.verify_flags

証明書検証操作のフラグ。 VERIFY_CRL_CHECK_LEAF のようなフラグは、それらをORで結合することによって設定できます。 デフォルトでは、OpenSSLは証明書失効リスト（CRL）を要求も検証もしません。 opensslバージョン0.9.8以降でのみ使用できます。

バージョン3.4の新機能。

バージョン3.6で変更： SSLContext.verify_flags は VerifyFlags フラグを返します。

>>> ssl.create_default_context().verify_flags  
<VerifyFlags.VERIFY_X509_TRUSTED_FIRST: 32768>
SSLContext.verify_mode

他のピアの証明書を検証するかどうか、および検証が失敗した場合の動作方法。 この属性は、 CERT_NONE 、 CERT_OPTIONAL 、または CERT_REQUIRED のいずれかである必要があります。

バージョン3.6で変更： SSLContext.verify_mode は VerifyMode 列挙型を返します：

>>> ssl.create_default_context().verify_mode
<VerifyMode.CERT_REQUIRED: 2>

証明書

一般に、証明書は公開鍵/秘密鍵システムの一部です。 このシステムでは、各プリンシパル（マシン、個人、または組織の場合があります）には、一意の2つの部分からなる暗号化キーが割り当てられます。 キーの一部は公開されており、公開キーと呼ばれます。 他の部分は秘密にされ、秘密鍵と呼ばれます。 2つの部分は関連しており、一方の部分でメッセージを暗号化すると、もう一方の部分でメッセージを復号化でき、もう一方の部分でのみを復号化できます。

証明書には、2つのプリンシパルに関する情報が含まれています。 サブジェクトの名前とサブジェクトの公開鍵が含まれています。 また、2番目のプリンシパルである発行者による、サブジェクトは彼らが主張する人物であり、これは実際にサブジェクトの公開鍵であるというステートメントも含まれています。 発行者のステートメントは、発行者だけが知っている発行者の秘密鍵で署名されています。 ただし、発行者の公開鍵を見つけ、それを使用してステートメントを復号化し、証明書内の他の情報と比較することで、誰でも発行者のステートメントを検証できます。 証明書には、有効期間に関する情報も含まれています。 これは、「notBefore」と「notAfter」という2つのフィールドとして表されます。

Pythonでの証明書の使用では、クライアントまたはサーバーは証明書を使用して自分が誰であるかを証明できます。 ネットワーク接続の反対側も証明書を生成する必要があり、その証明書は、そのような検証を必要とするクライアントまたはサーバーが満足するように検証できます。 検証が失敗した場合に例外を発生させるように接続試行を設定できます。 検証は、基盤となるOpenSSLフレームワークによって自動的に行われます。 アプリケーションは、そのメカニズムに関係する必要はありません。 ただし、アプリケーションは通常、このプロセスを実行できるようにするために証明書のセットを提供する必要があります。

Pythonは、ファイルを使用して証明書を格納します。 これらは「PEM」（ RFC 1422 を参照）としてフォーマットする必要があります。これは、ヘッダー行とフッター行でラップされたbase-64エンコード形式です。 

-----BEGIN CERTIFICATE-----
... (certificate in base64 PEM encoding) ...
-----END CERTIFICATE-----

証明書チェーン

証明書を含むPythonファイルには、証明書チェーンと呼ばれることもある一連の証明書を含めることができます。 このチェーンは、クライアントまたはサーバーであるプリンシパルの特定の証明書、その証明書の発行者の証明書、その証明書の発行者の証明書などで開始する必要があります。 自己署名である証明書、つまり、同じサブジェクトと発行者を持つ証明書（ルート証明書と呼ばれることもあります）に到達するまで、チェーンを上っていきます。 証明書は、証明書ファイルで連結する必要があります。 たとえば、サーバー証明書から、サーバー証明書に署名した認証局の証明書、認証局の証明書を発行した機関のルート証明書まで、3つの証明書チェーンがあるとします。 

-----BEGIN CERTIFICATE-----
... (certificate for your server)...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (the certificate for the CA)...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (the root certificate for the CA's issuer)...
-----END CERTIFICATE-----

CA証明書

接続の証明書の反対側の検証が必要な場合は、信頼できる各発行者の証明書チェーンが入った「CA証明書」ファイルを提供する必要があります。 繰り返しますが、このファイルには、これらのチェーンが連結されたものが含まれています。 検証のために、Pythonはファイル内で見つかった最初のチェーンを使用して一致します。 プラットフォームの証明書ファイルは、 SSLContext.load_default_certs（）を呼び出すことで使用できます。これは、 create_default_context（）で自動的に行われます。


キーと証明書の組み合わせ

多くの場合、秘密鍵は証明書と同じファイルに保存されます。 この場合、 SSLContext.load_cert_chain（）および wrap_socket（）へのcertfileパラメーターのみを渡す必要があります。 秘密鍵が証明書とともに保存されている場合は、証明書チェーンの最初の証明書の前にある必要があります。 

-----BEGIN RSA PRIVATE KEY-----
... (private key in base64 encoding) ...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
... (certificate in base64 PEM encoding) ...
-----END CERTIFICATE-----

自己署名証明書

SSL暗号化接続サービスを提供するサーバーを作成する場合は、そのサービスの証明書を取得する必要があります。 認証局から証明書を購入するなど、適切な証明書を取得する方法はたくさんあります。 もう1つの一般的な方法は、自己署名証明書を生成することです。 これを行う最も簡単な方法は、次のようなものを使用して、OpenSSLパッケージを使用することです。 

% openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem
Generating a 1024 bit RSA private key
.......++++++
.............................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:MyState
Locality Name (eg, city) []:Some City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Organization, Inc.
Organizational Unit Name (eg, section) []:My Group
Common Name (eg, YOUR name) []:myserver.mygroup.myorganization.com
Email Address []:[email protected]
%

自己署名証明書の欠点は、それが独自のルート証明書であり、既知の（および信頼できる）ルート証明書のキャッシュに他の誰もそれを持たないことです。


例

SSLサポートのテスト

PythonインストールでSSLサポートが存在するかどうかをテストするには、ユーザーコードで次のイディオムを使用する必要があります。 

try:
    import ssl
except ImportError:
    pass
else:
    ...  # do something that requires SSL support

クライアント側の操作

この例では、自動証明書検証など、クライアントソケットに推奨されるセキュリティ設定を使用してSSLコンテキストを作成します。 

>>> context = ssl.create_default_context()

セキュリティ設定を自分で調整したい場合は、コンテキストを最初から作成することもできます（ただし、設定が正しく行われない可能性があることに注意してください）。 

>>> context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
>>> context.load_verify_locations("/etc/ssl/certs/ca-bundle.crt")

（このスニペットは、オペレーティングシステムがすべてのCA証明書のバンドルを/etc/ssl/certs/ca-bundle.crtに配置することを前提としています。そうでない場合、エラーが発生し、場所を調整する必要があります）

PROTOCOL_TLS_CLIENT プロトコルは、証明書の検証とホスト名の検証のコンテキストを構成します。 verify_mode は CERT_REQUIRED に設定され、 check_hostname はTrueに設定されます。 他のすべてのプロトコルは、安全でないデフォルトでSSLコンテキストを作成します。

コンテキストを使用してサーバーに接続する場合、 CERT_REQUIRED および check_hostname はサーバー証明書を検証します。サーバー証明書がCA証明書のいずれかで署名されていることを確認し、正確性、およびホスト名の有効性やIDなどの他のプロパティを検証します。 

>>> conn = context.wrap_socket(socket.socket(socket.AF_INET),
...                            server_hostname="www.python.org")
>>> conn.connect(("www.python.org", 443))

次に、証明書を取得できます。 

>>> cert = conn.getpeercert()

目視検査は、証明書が目的のサービス（つまり、HTTPSホストwww.python.org）を識別していることを示しています。 

>>> pprint.pprint(cert)
{'OCSP': ('http://ocsp.digicert.com',),
 'caIssuers': ('http://cacerts.digicert.com/DigiCertSHA2ExtendedValidationServerCA.crt',),
 'crlDistributionPoints': ('http://crl3.digicert.com/sha2-ev-server-g1.crl',
                           'http://crl4.digicert.com/sha2-ev-server-g1.crl'),
 'issuer': ((('countryName', 'US'),),
            (('organizationName', 'DigiCert Inc'),),
            (('organizationalUnitName', 'www.digicert.com'),),
            (('commonName', 'DigiCert SHA2 Extended Validation Server CA'),)),
 'notAfter': 'Sep  9 12:00:00 2016 GMT',
 'notBefore': 'Sep  5 00:00:00 2014 GMT',
 'serialNumber': '01BB6F00122B177F36CAB49CEA8B6B26',
 'subject': ((('businessCategory', 'Private Organization'),),
             (('1.3.6.1.4.1.311.60.2.1.3', 'US'),),
             (('1.3.6.1.4.1.311.60.2.1.2', 'Delaware'),),
             (('serialNumber', '3359300'),),
             (('streetAddress', '16 Allen Rd'),),
             (('postalCode', '03894-4801'),),
             (('countryName', 'US'),),
             (('stateOrProvinceName', 'NH'),),
             (('localityName', 'Wolfeboro'),),
             (('organizationName', 'Python Software Foundation'),),
             (('commonName', 'www.python.org'),)),
 'subjectAltName': (('DNS', 'www.python.org'),
                    ('DNS', 'python.org'),
                    ('DNS', 'pypi.org'),
                    ('DNS', 'docs.python.org'),
                    ('DNS', 'testpypi.org'),
                    ('DNS', 'bugs.python.org'),
                    ('DNS', 'wiki.python.org'),
                    ('DNS', 'hg.python.org'),
                    ('DNS', 'mail.python.org'),
                    ('DNS', 'packaging.python.org'),
                    ('DNS', 'pythonhosted.org'),
                    ('DNS', 'www.pythonhosted.org'),
                    ('DNS', 'test.pythonhosted.org'),
                    ('DNS', 'us.pycon.org'),
                    ('DNS', 'id.python.org')),
 'version': 3}

これでSSLチャネルが確立され、証明書が検証されたので、サーバーとの通信に進むことができます。 

>>> conn.sendall(b"HEAD / HTTP/1.0\r\nHost: linuxfr.org\r\n\r\n")
>>> pprint.pprint(conn.recv(1024).split(b"\r\n"))
[b'HTTP/1.1 200 OK',
 b'Date: Sat, 18 Oct 2014 18:27:20 GMT',
 b'Server: nginx',
 b'Content-Type: text/html; charset=utf-8',
 b'X-Frame-Options: SAMEORIGIN',
 b'Content-Length: 45679',
 b'Accept-Ranges: bytes',
 b'Via: 1.1 varnish',
 b'Age: 2188',
 b'X-Served-By: cache-lcy1134-LCY',
 b'X-Cache: HIT',
 b'X-Cache-Hits: 11',
 b'Vary: Cookie',
 b'Strict-Transport-Security: max-age=63072000; includeSubDomains',
 b'Connection: close',
 b'',
 b'']

以下のセキュリティに関する考慮事項の説明を参照してください。


サーバー側の操作

サーバーの操作では、通常、サーバー証明書と秘密鍵がそれぞれファイルに含まれている必要があります。 最初に、キーと証明書を保持するコンテキストを作成して、クライアントがあなたの信頼性を確認できるようにします。 次に、ソケットを開き、それをポートにバインドし、そのソケットでlisten()を呼び出し、クライアントが接続するのを待ち始めます。 

import socket, ssl

context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
context.load_cert_chain(certfile="mycertfile", keyfile="mykeyfile")

bindsocket = socket.socket()
bindsocket.bind(('myaddr.mydomain.com', 10023))
bindsocket.listen(5)

クライアントが接続するときに、ソケットでaccept()を呼び出して、もう一方の端から新しいソケットを取得し、コンテキストの SSLContext.wrap_socket（）メソッドを使用してサーバー側を作成します。接続用のSSLソケット： 

while True:
    newsocket, fromaddr = bindsocket.accept()
    connstream = context.wrap_socket(newsocket, server_side=True)
    try:
        deal_with_client(connstream)
    finally:
        connstream.shutdown(socket.SHUT_RDWR)
        connstream.close()

次に、connstreamからデータを読み取り、クライアントで終了するまで（または、クライアントで終了するまで）、それを使用して何かを実行します。 

def deal_with_client(connstream):
    data = connstream.recv(1024)
    # empty data means the client is finished with us
    while data:
        if not do_something(connstream, data):
            # we'll assume do_something returns False
            # when we're finished with client
            break
        data = connstream.recv(1024)
    # finished with client

そして、新しいクライアント接続のリッスンに戻ります（もちろん、実サーバーは各クライアント接続を別々のスレッドで処理するか、ソケットを非ブロッキングモードにしてイベントループを使用します）。


ノンブロッキングソケットに関する注意

SSLソケットは、非ブロッキングモードの通常のソケットとは少し異なる動作をします。 したがって、非ブロッキングソケットを使用する場合は、次の点に注意する必要があります。

  • ほとんどの SSLSocket メソッドは、I / O操作がブロックされる場合、 BlockingIOError ではなく SSLWantWriteError または SSLWantReadError のいずれかを発生させます。 SSLWantReadError は、基になるソケットでの読み取り操作が必要な場合に発生し、 SSLWantWriteError は、基になるソケットでの書き込み操作で発生します。 SSLソケットに書き込みしようとすると、最初に基になるソケットから読み取りが必要になる場合があり、SSLソケットから読み取りしようとすると、事前にが必要になる場合があります。 ]基になるソケットにを書き込みます。

    バージョン3.5での変更：以前のPythonバージョンでは、 SSLWantWriteError または SSLWantReadError を発生させる代わりに、SSLSocket.send()メソッドがゼロを返しました。

  • select（）を呼び出すと、OSレベルのソケットを読み取り（または書き込み）できることがわかりますが、SSLの上位層に十分なデータがあることを意味するわけではありません。 たとえば、SSLフレームの一部のみが到着した可能性があります。 したがって、SSLSocket.recv()およびSSLSocket.send()の障害を処理する準備ができており、 select（）をもう一度呼び出してから再試行する必要があります。

  • 逆に、SSLレイヤーには独自のフレーミングがあるため、SSLソケットには、 select（）が認識していなくても読み取り可能なデータが残っている可能性があります。 したがって、最初にSSLSocket.recv()を呼び出して、利用可能な可能性のあるデータをすべて排出してから、必要な場合にのみ select（）呼び出しをブロックする必要があります。

    （もちろん、 poll（）やセレクターモジュールのプリミティブなどの他のプリミティブを使用する場合も同様の規定が適用されます）

  • SSLハンドシェイク自体は非ブロッキングになります。 SSLSocket.do_handshake（）メソッドは、正常に戻るまで再試行する必要があります。 select（）を使用してソケットの準備が整うのを待つ概要は次のとおりです。

    while True:
    try:
        sock.do_handshake()
        break
    except ssl.SSLWantReadError:
        select.select([sock], [], [])
    except ssl.SSLWantWriteError:
        select.select([], [sock], [])

も参照してください

asyncio モジュールは、ノンブロッキングSSLソケットをサポートし、より高いレベルのAPIを提供します。 セレクターモジュールを使用してイベントをポーリングし、 SSLWantWriteError 、 SSLWantReadError 、および BlockingIOError 例外を処理します。 SSLハンドシェイクも非同期で実行されます。


メモリBIOサポート

バージョン3.5の新機能。


SSLモジュールがPython2.6で導入されて以来、 SSLSocket クラスは、2つの関連するが異なる機能領域を提供してきました。

  • SSLプロトコルの処理
  • ネットワークIO

ネットワークIOAPIは、 socket.socket によって提供されるものと同じであり、 SSLSocket も継承します。 これにより、SSLソケットを通常のソケットのドロップイン代替として使用できるようになり、既存のアプリケーションにSSLサポートを非常に簡単に追加できるようになります。

通常、SSLプロトコル処理とネットワークIOの組み合わせはうまく機能しますが、うまくいかない場合もあります。 例として、 socket.socket および内部OpenSSLソケットによって想定される「ファイル記述子の選択/ポーリング」（準備ベース）モデルとは異なるIO多重化モデルを使用する非同期IOフレームワークがあります。 IOルーチン。 これは主に、このモデルが効率的でないWindowsなどのプラットフォームに関連しています。 この目的のために、 SSLObject と呼ばれる SSLSocket のスコープが縮小されたバリアントが提供されます。

class ssl.SSLObject

ネットワークIOメソッドを含まないSSLプロトコルインスタンスを表す SSLSocket のスコープを縮小したバリアント。 このクラスは通常、メモリバッファを介してSSLの非同期IOを実装したいフレームワークの作成者によって使用されます。

このクラスは、OpenSSLによって実装される低レベルSSLオブジェクトの上にインターフェースを実装します。 このオブジェクトはSSL接続の状態をキャプチャしますが、ネットワークIO自体は提供しません。 IOは、OpenSSLのIO抽象化レイヤーである個別の「BIO」オブジェクトを介して実行する必要があります。

このクラスにはパブリックコンストラクターがありません。 SSLObject インスタンスは、 wrap_bio（）メソッドを使用して作成する必要があります。 このメソッドは、 SSLObject インスタンスを作成し、それをBIOのペアにバインドします。 着信 BIOはPythonからSSLプロトコルインスタンスにデータを渡すために使用され、発信 BIOは逆にデータを渡すために使用されます。

次の方法を使用できます。

SSLSocket と比較すると、このオブジェクトには次の機能がありません。

  • あらゆる形式のネットワークIO。 recv()およびsend()は、基になる MemoryBIO バッファーに対してのみ読み取りおよび書き込みを行います。

  • do_handshake_on_connect 機構はありません。 ハンドシェイクを開始するには、常に do_handshake（）を手動で呼び出す必要があります。

  • suppress_ragged_eofs の処理はありません。 プロトコルに違反しているすべてのファイルの終わりの状態は、 SSLEOFError 例外を介して報告されます。

  • メソッド unwrap（）呼び出しは、基になるソケットを返すSSLソケットとは異なり、何も返しません。

  • SSLContext.set_servername_callback（）に渡された server_name_callback コールバックは、最初のパラメーターとして SSLSocket インスタンスではなく SSLObject インスタンスを取得します。

SSLObject の使用に関連するいくつかの注意事項：

バージョン3.7で変更： SSLObject インスタンスは、 wrap_bio（）で作成する必要があります。 以前のバージョンでは、インスタンスを直接作成することが可能でした。 これは文書化されておらず、公式にサポートされていません。

SSLObjectは、メモリバッファを使用して外部と通信します。 クラス MemoryBIO は、この目的に使用できるメモリバッファを提供します。 OpenSSLメモリBIO（基本IO）オブジェクトをラップします。

class ssl.MemoryBIO

PythonとSSLプロトコルインスタンス間でデータを渡すために使用できるメモリバッファ。

pending

現在メモリバッファにあるバイト数を返します。

eof

メモリBIOがファイルの終わりの位置で現在のものであるかどうかを示すブール値。

read(n=- 1)

メモリバッファから最大 n バイトを読み取ります。 n が指定されていないか負の場合、すべてのバイトが返されます。

write(buf)

buf からメモリBIOにバイトを書き込みます。 buf 引数は、バッファプロトコルをサポートするオブジェクトである必要があります。

戻り値は書き込まれたバイト数であり、常に buf の長さに等しくなります。

write_eof()

EOFマーカーをメモリBIOに書き込みます。 このメソッドが呼び出された後、 write（）を呼び出すことは違法です。 属性 eof は、現在バッファーにあるすべてのデータが読み取られた後にtrueになります。


SSLセッション

バージョン3.6の新機能。


class ssl.SSLSession

セッションによって使用されるセッションオブジェクト。

id
time
timeout
ticket_lifetime_hint
has_ticket


セキュリティに関する考慮事項

最良のデフォルト

クライアント使用の場合、セキュリティポリシーに特別な要件がない場合は、 create_default_context（）関数を使用してSSLコンテキストを作成することを強くお勧めします。 システムの信頼できるCA証明書をロードし、証明書の検証とホスト名のチェックを有効にして、適度に安全なプロトコルと暗号の設定を選択しようとします。

たとえば、 smtplib.SMTP クラスを使用して、SMTPサーバーへの信頼できる安全な接続を作成する方法は次のとおりです。 

>>> import ssl, smtplib
>>> smtp = smtplib.SMTP("mail.python.org", port=587)
>>> context = ssl.create_default_context()
>>> smtp.starttls(context=context)
(220, b'2.0.0 Ready to start TLS')

接続にクライアント証明書が必要な場合は、 SSLContext.load_cert_chain（）で追加できます。

対照的に、 SSLContext コンストラクターを自分で呼び出してSSLコンテキストを作成する場合、デフォルトでは証明書の検証もホスト名のチェックも有効になりません。 その場合は、以下の段落を読んで、適切なセキュリティレベルを達成してください。


手動設定

証明書の検証

SSLContext コンストラクターを直接呼び出す場合、 CERT_NONE がデフォルトです。 他のピアを認証しないため、特にクライアントモードでは安全でない可能性があります。クライアントモードでは、ほとんどの場合、通信しているサーバーの信頼性を確保する必要があります。 したがって、クライアントモードの場合は、 CERT_REQUIRED を使用することを強くお勧めします。 ただし、それ自体では十分ではありません。 また、 SSLSocket.getpeercert（）を呼び出して取得できるサーバー証明書が目的のサービスと一致することを確認する必要があります。 多くのプロトコルとアプリケーションでは、サービスはホスト名で識別できます。 この場合、 match_hostname（）関数を使用できます。 この一般的なチェックは、 SSLContext.check_hostname が有効になっている場合に自動的に実行されます。

バージョン3.7で変更：ホスト名の照合がOpenSSLによって実行されるようになりました。 Pythonは match_hostname（）を使用しなくなりました。


サーバーモードで、（高レベルの認証メカニズムを使用するのではなく）SSLレイヤーを使用してクライアントを認証する場合は、 CERT_REQUIRED も指定し、同様にクライアント証明書を確認する必要があります。


プロトコルバージョン

SSLバージョン2および3は安全でないと見なされるため、使用するのは危険です。 クライアントとサーバー間の互換性を最大限に高めたい場合は、プロトコルバージョンとして PROTOCOL_TLS_CLIENT または PROTOCOL_TLS_SERVER を使用することをお勧めします。 SSLv2とSSLv3はデフォルトで無効になっています。 

>>> client_context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
>>> client_context.options |= ssl.OP_NO_TLSv1
>>> client_context.options |= ssl.OP_NO_TLSv1_1

上で作成されたSSLコンテキストは、サーバーへのTLSv1.2以降（システムでサポートされている場合）の接続のみを許可します。 PROTOCOL_TLS_CLIENT は、デフォルトで証明書の検証とホスト名のチェックを意味します。 証明書をコンテキストにロードする必要があります。


暗号の選択

高度なセキュリティ要件がある場合は、 SSLContext.set_ciphers（）メソッドを使用して、SSLセッションのネゴシエーション時に有効になっている暗号を微調整できます。 Python 3.2.3以降、sslモジュールはデフォルトで特定の弱い暗号を無効にしますが、暗号の選択をさらに制限したい場合があります。 暗号リスト形式に関するOpenSSLのドキュメントを必ずお読みください。 特定の暗号リストで有効になっている暗号を確認する場合は、システムで SSLContext.get_ciphers（）またはopenssl ciphersコマンドを使用してください。


マルチプロセッシング

このモジュールをマルチプロセスアプリケーションの一部として使用する場合（たとえば、 multiprocessing または concurrent.futures モジュールを使用する場合）、OpenSSLの内部乱数ジェネレーターが適切に処理しないことに注意してください。フォークされたプロセス。 アプリケーションが os.fork（）でSSL機能を使用する場合、アプリケーションは親プロセスのPRNG状態を変更する必要があります。 RAND_add（）、 RAND_bytes（）、または RAND_pseudo_bytes（）の呼び出しが成功すれば十分です。


TLS 1.3

バージョン3.7の新機能。


Pythonは、OpenSSL1.1.1を使用したTLS1.3の暫定的および実験的なサポートを提供しています。 新しいプロトコルは、以前のバージョンのTLS / SSLとは少し異なる動作をします。 一部の新しいTLS1.3機能はまだ利用できません。

  • TLS 1.3は、分離した暗号スイートのセットを使用します。 すべてのAES-GCMおよびChaCha20暗号スイートはデフォルトで有効になっています。 メソッド SSLContext.set_ciphers（）は、TLS 1.3暗号をまだ有効または無効にすることはできませんが、 SSLContext.get_ciphers（）はそれらを返します。
  • セッションチケットは、最初のハンドシェイクの一部として送信されなくなり、処理が異なります。 SSLSocket.session および SSLSession はTLS1.3と互換性がありません。
  • クライアント側の証明書も、最初のハンドシェイク中に検証されなくなりました。 サーバーはいつでも証明書を要求できます。 クライアントは、サーバーとの間でアプリケーションデータを送受信しているときに、証明書要求を処理します。
  • 初期データ、遅延TLSクライアント証明書要求、署名アルゴリズム構成、キーの再生成などのTLS1.3機能はまだサポートされていません。


LibreSSLのサポート

LibreSSLは、OpenSSL1.0.1のフォークです。 sslモジュールはLibreSSLのサポートが制限されています。 sslモジュールがLibreSSLでコンパイルされている場合、一部の機能は使用できません。

も参照してください

クラス socket.socket

基礎となるソケットクラスのドキュメント

SSL / TLSストロングエンクリプト：はじめに

ApacheHTTPサーバーのドキュメントからの紹介

RFC 1422：インターネット電子メールのプライバシー強化：パートII：証明書ベースの鍵管理

スティーブケント

RFC 4086：セキュリティのランダム性要件

ドナルドE.、ジェフリーI. シラー

RFC 5280：インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル

  1. クーパー

RFC 5246：トランスポート層セキュリティ（TLS）プロトコルバージョン1.2

  1. Dierkset。 al。

RFC 6066：トランスポート層セキュリティ（TLS）拡張

  1. イーストレイク

IANA TLS：トランスポート層セキュリティ（TLS）パラメーター

IANA

RFC 7525：トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の安全な使用に関する推奨事項

IETF

Mozillaのサーバー側TLSの推奨事項

Mozilla



「https://www.finddevguides.com/index.php?title=Python/docs/3.8/library/ssl&oldid=99194」から取得
Powered by MediaWiki