HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。このような場合は、暗号化された (安全な) プロトコルを使用する必要があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが送信されます。

...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...

受信する HttpResponse オブジェクトである res は、暗号化も認証もされていないチャネルを介して送信されるため、危険にさらされる可能性があります。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、デバイスが WiFi 接続を経由して安全ではない公共のワイヤレス ネットワークに接続されることの多い場合、中間者 (Man-in-the-Middle) 攻撃にさらされる可能性があります。

例 1: 次のコードでは、(HTTPS プロトコルではなく) 安全でない HTTP プロトコルを使用しています。

    var account = new CloudStorageAccount(storageCredentials, false);

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

  ...
  String url = 'http://10.0.2.2:11005/v1/key';
  Response response = await get(url, headers: headers);
  ...

入力レスポンス response は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特にデバイスがセキュリティで保護されていないパブリック ワイヤレス ネットワークに頻繁に接続される環境では、リスクに晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用して Web サーバーがセットアップされます。

	helloHandler := func(w http.ResponseWriter, req *http.Request) {
		io.WriteString(w, "Hello, world!\n")
	}

	http.HandleFunc("/hello", helloHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

var http = require('http');
...
http.request(options, function(res){
  ...
});
...

入力 http.IncomingMessage オブジェクトの res は、暗号化されていない未認証のチャネルを介して配信されるので危険にさらされています。

HTTP 経由で送信されるデータはすべて平文で送信されるため、攻撃を受ける可能性があります。

例 1: 次の例では、(HTTPS ではなく) HTTP プロトコル経由でデータが送信されます。

NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特にデバイスがセキュリティで保護されていないパブリック ワイヤレス ネットワークに頻繁に接続される環境では、リスクに晒される可能性があります。

例 1: 次の例では、ソケットの暗号化を無効にします。

...
stream_socket_enable_crypto($fp, false);
...

安全でない、暗号化されていない、または平文のプロトコルで送信されるすべての通信は、危険にさらされる可能性があります。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、悪用される対象となります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...

入力ストリーム in は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。

HTTP、FTP、または gopher 上のすべての通信は、認証されることはなく、暗号化も行われていません。したがって、特に、デバイスが WiFi 接続を経由して安全ではない公衆ワイヤレスネットワークに接続されることの多いモバイル環境では、危険に晒される可能性があります。

例 1: 次の例では、(HTTPS プロトコルではなく) HTTP プロトコルを使用してデータが読み込まれます。

   val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
   val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))

入力レスポンス responseFutureは、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。

HTTP 経由で送信されるデータはすべて平文で送信されるため、攻撃を受ける可能性があります。

例 1: 次の例では、(HTTPS ではなく) HTTP プロトコル経由でデータが送信されます。

let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)

暗号スイートは、安全な通信を確立するために使用されるアルゴリズムのセットです。サーバーとクライアント間の接続を確立する際、通常、サーバーは相互にサポートされている暗号スイートのうち、どの暗号スイートを使用するかを決定します。サーバとクライアントでは、サポートする暗号スイートのセットが異なる場合があります。古い暗号スイートは一般的に推奨されず、アプリケーションにセキュリティ上の脆弱性をもたらす可能性があります。一般的には、セキュリティ上の脆弱性が知られていない強力な暗号スイートの使用が推奨されています。

サーバーの優先暗号スイートに、既知の脆弱性を持つ暗号スイートが含まれている可能性があります。ユーザーが脆弱な暗号スイートを選択した場合、既知の弱点を持つ暗号スイートを選択して、セキュリティ脆弱性の導入を試みることが可能になります。

例 1: 次の Paramiko コードでは、攻撃者が無効なアルゴリズムのリストを設定して、暗号をダウングレードできるようになっています。

    client = SSHClient()
    algorithms_to_disable = { "ciphers": untrusted_user_input }
    client.connect(host, port, "user", "password", disabled_algorithms=algorithms_to_disable)

Paramiko では、開発者が暗号解読スイートを選択できるようになっています。Paramiko が推奨するアルゴリズムは、AES128-CTR、AES192-CTR、AES256-CTR、AES128-CBC、AES192-CBC、AES256-CBC、3DES-CBC です。攻撃者がどのアルゴリズムを無効にするかを制御できる場合、SSHClient.connect(...) に、より弱いアルゴリズム 3DES-CBC を使用するように強制することができます。

アプリケーションは、暗号化されていないチャネルを介してデータベース サーバーと通信するため、会社とアプリケーション ユーザーに重大なセキュリティ リスクをもたらす可能性があります。この場合、攻撃者はユーザーが入力したデータを変更したり、データベース サーバーに対して任意の SQL コマンドを実行したりする可能性があります。

例 1: 次のコードにより、アプリケーションは、暗号化されていないチャネルを介してデータベース サーバーと通信します。

  ...
  insecure_config = {
        'user': username,
        'password': retrievedPassword,
        'host': databaseHost,
        'port': "3306",
        'ssl_disabled': True
    }

    mysql.connector.connect(**insecure_config)
  ...

暗号化の指定なし、認証の非サポート、または接続 ID の容量なしとして指定されている Google Remote Procedure Call (gRPC) チャネル セキュリティ設定を使用すると、チャネルはさまざまな形式の攻撃に対して無防備になります。この安全でないチャネルで送信されたデータは信頼できません。

例 1: 次のコードは、安全でないチャネル資格情報を使用した gRPC チャネルのセットアップを示しています。

    ...
    using var channel = GrpcChannel.ForAddress("https://grpcserver.com", new GrpcChannelOptions { 
        Credentials = ChannelCredentials.Insecure
    });
    ...
    

未指定の Google Remote Procedure Call (gRPC) チャネル資格情報設定を使用すると、セキュリティ設定が、安全でないデフォルト値である None に設定されます。安全でないチャネル資格情報設定で送信されたデータは信頼できません。

例 1: 次のコードは、デフォルトのすべてのパラメーターを使用して作成された gRPC チャネル資格情報オブジェクトを示しています。これにより、すべてのチャネル資格情報のセキュリティ設定は、安全でないデフォルト値に設定されます。このインスタンスでは、root_certificates パラメーターの値が None に設定され、private_key パラメーターの値が None に設定され、certificate_chain パラメーターの値が None に設定されます。

...
channel_creds = grpc.ssl_channel_credentials()
...

未指定の Google Remote Procedure Call (gRPC) サーバー資格情報設定を使用すると、セキュリティ設定が、安全でないデフォルト値である None または False に設定されます。安全でないサーバー資格情報設定を使用したサーバーとの間で送受信されるデータは信頼できません。

例 1: 次のコードは、デフォルトのパラメーターを使用して作成された gRPC サーバー資格情報オブジェクトを示しています。これにより、クライアント認証が無効になります。

...
pk_cert_chain = your_organization.securelyGetPrivateKeyCertificateChainPairs()
server_creds = grpc.ssl_server_credentials(pk_cert_chain)
...

HTTPS Stripping 攻撃は Man-In-The-Middle 攻撃の一種であり、攻撃者はすべての HTTP トラフィックを監視し、HTTPS を参照する位置ヘッダーおよびリンクを見つけ、HTTPS の位置ヘッダーとリンクを HTTP のものに置換します。攻撃者は HTTPS リクエストをサーバーに戻せるように、すべての HTTP 代用の一覧を作成します。見つけ出された HTTP 接続はすべて HTTPS 経由でサーバーにプロキシされます。攻撃対象者と攻撃者の間のトラフィックはすべて HTTP で送信され、ユーザー名、パスワード、その他の個人情報が開示されますが、サーバーは要求通り HTTPS トラフィックを攻撃者から受け取るため、何も問題ないように見えます。

HTTP Strict Transport Security (HSTS) は、ヘッダー自体に指定されている期間に SSL/TLS で HSTS ヘッダーを返すサイトに常に接続するよう、ブラウザに指示するセキュリティ ヘッダーです。ユーザーがブラウザの URL バーに「http://」と入力しても、HTTP によるサーバーへの接続は自動的に HTTPS に置換されます。

HTTPS Stripping 攻撃は Man-In-The-Middle 攻撃の一種であり、攻撃者はすべての HTTP トラフィックを監視し、HTTPS を参照する位置ヘッダーおよびリンクを見つけ、HTTPS の位置ヘッダーとリンクを HTTP のものに置換します。攻撃者は HTTPS リクエストをサーバーに戻せるように、すべての HTTP 代用の一覧を作成します。見つけ出された HTTP 接続はすべて HTTPS 経由でサーバーにプロキシされます。攻撃対象者と攻撃者の間のトラフィックはすべて HTTP で送信され、ユーザー名、パスワード、その他の個人情報が開示されますが、サーバーは要求通り HTTPS トラフィックを攻撃者から受け取るため、何も問題ないように見えます。

HTTP Strict Transport Security (HSTS) は、ヘッダー自体に指定されている期間に SSL/TLS で HSTS ヘッダーを返すサイトに常に接続するよう、ブラウザに指示するセキュリティ ヘッダーです。ユーザーがブラウザの URL バーに「http://」と入力しても、HTTP によるサーバーへの接続は自動的に HTTPS に置換されます。

HTTPS Stripping 攻撃は Man-In-The-Middle 攻撃の一種であり、攻撃者はすべての HTTP トラフィックを監視し、HTTPS を参照する位置ヘッダーおよびリンクを見つけ、HTTPS の位置ヘッダーとリンクを HTTP のものに置換します。攻撃者は HTTPS リクエストをサーバーに戻せるように、すべての HTTP 代用の一覧を作成します。見つけ出された HTTP 接続はすべて HTTPS 経由でサーバーにプロキシされます。攻撃対象者と攻撃者の間のトラフィックはすべて HTTP で送信され、ユーザー名、パスワード、その他の個人情報が開示されますが、サーバーは要求通り HTTPS トラフィックを攻撃者から受け取るため、何も問題ないように見えます。

HTTP Strict Transport Security (HSTS) は、ヘッダー自体に指定されている期間に SSL/TLS で HSTS ヘッダーを返すサイトに常に接続するよう、ブラウザに指示するセキュリティ ヘッダーです。ユーザーがブラウザの URL バーに「http://」と入力しても、HTTP によるサーバーへの接続は自動的に HTTPS に置換されます。

HTTPS Stripping 攻撃は Man-In-The-Middle 攻撃の一種であり、攻撃者はすべての HTTP トラフィックを監視し、HTTPS を参照する位置ヘッダーおよびリンクを見つけ、HTTPS の位置ヘッダーとリンクを HTTP のものに置換します。攻撃者は HTTPS リクエストをサーバーに戻せるように、すべての HTTP 代用の一覧を作成します。見つけ出された HTTP 接続はすべて HTTPS 経由でサーバーにプロキシされます。攻撃対象者と攻撃者の間のトラフィックはすべて HTTP で送信され、ユーザー名、パスワード、その他の個人情報が開示されますが、サーバーは要求通り HTTPS トラフィックを攻撃者から受け取るため、何も問題ないように見えます。

HTTP Strict Transport Security (HSTS) は、ヘッダー自体に指定されている期間に SSL/TLS で HSTS ヘッダーを返すサイトに常に接続するよう、ブラウザに指示するセキュリティ ヘッダーです。ユーザーがブラウザの URL バーに「http://」と入力しても、HTTP によるサーバーへの接続は自動的に HTTPS に置換されます。

暗号化されずにネットワークで送信される機密データは、ネットワーク トラフィックを傍受できる攻撃者によって読み取られたり、改変されたりする可能性があります。

例 1: 次の SmtpClient は SMTP サーバーと通信するために SSL/TLS を使用しておらず、設定が正しくありません。

  string to = "bob@acme.com";
  string from = "alice@acme.com";
  MailMessage message = new MailMessage(from, to);
  message.Subject = "SMTP client.";
  message.Body = @"You can send an email message from an application very easily.";
  SmtpClient client = new SmtpClient("smtp.acme.com");
  client.UseDefaultCredentials = true;
  client.Send(message);

暗号化されずにネットワークで送信される機密データは、ネットワーク トラフィックを傍受できる攻撃者によって読み取られたり、改変されたりする可能性があります。

例 1: 次の SMTP クライアントは、SMTP サーバーと通信するために SSL/TLS を使用しておらず、設定が正しくありません。

session = smtplib.SMTP(smtp_server, smtp_port)
session.ehlo()
session.login(username, password)
session.sendmail(frm, to, content)

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱である可能性があり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

データ送信の信頼性、機密性、および整合性を確保するために SSL/TLS を使用するアプリケーションは、十分に強力な暗号化アルゴリズムを選択しないと、侵害に対して脆弱になる可能性があります。保護メカニズムの強度は、認証、暗号化、およびハッシュ アルゴリズムによって決まります。これらのアルゴリズムは、まとめて暗号スイートと呼ばれます。暗号スイートは、TLS/SSL チャネルを介した機密情報の送信に使用されます。

サーバーが、強度の異なるさまざまな暗号スイートをサポートしている場合、脆弱な暗号または不十分な長さの暗号化キーを使用すると、攻撃者が保護メカニズムを打ち破り、機密情報を盗んだり変更したりする可能性があります。攻撃者が、安全に構成されていない Web サーバーに置かれたアプリケーションを操作して、脆弱な暗号スイートを選択する可能性があります。脆弱な暗号スイートは、ブルートフォース攻撃や中間者攻撃に対して脆弱であり、それが機密データの傍受や操作につながる可能性があります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

例 1: 次の Node.js スニペットは、セキュア接続でサーバーを作成しようとします。

...
var options = {
  port: 443,
  path: '/',
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  ...
}
https.createServer(options);
...

Node.js は secureProtocol のデフォルト値を SSLv23_method に設定するので、secureProtocol を明確にオーバーライドしなければ、サーバーは本質的に安全ではなくなります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。新しい改訂では毎回、前のバージョンで見つかったセキュリティの脆弱性に対応しています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が弱まり、攻撃者による機密情報の侵害、盗難、改変の可能性が生じます。

安全でないバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

例 1: 次の例では、デフォルトの SSL バージョン (SSL v3.0) を使用しています。

NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration ephemeralSessionConfiguration];
[configuration setTLSMinimumSupportedProtocol = kSSLProtocol3];
NSURLSession *mySession = [NSURLSession sessionWithConfiguration:configuration delegate:self delegateQueue:operationQueue];

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。それぞれの新リビジョンは、以前のバージョンで見つかったセキュリティの脆弱性を解決するために設計されています。安全ではない TLS/SSL のバージョンを使用すると、データ保護の強度が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

脆弱なバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない
- 脆弱な暗号スイートが使用される

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

例 1: 次の例では、SSL v3.0 を使用するようにセッションを構成します。

let configuration : NSURLSessionConfiguration = NSURLSessionConfiguration.defaultSessionConfiguration()
let mySession = NSURLSession(configuration: configuration, delegate: self, delegateQueue: operationQueue)