Performing Ssl Tls Security Assessment

TL;DR

• 目的：>- Assess SSL/TLS server configurations using the sslyze Python scanning library to evaluate supported protocol versions, cipher suite stren…
• 适用：云/K8s/容器/配置审计
• 输入：目标 URL + 端点/参数清单
• 输出：配置审计报告 + 修复建议
• 红线：仅限授权范围内；破坏性 POC 先用只读变体；全 RCE 前明确批准
• 关联：上游：003-src-session-start → 下游：043-hunt-nosqli, 027-hunt-cors, 028-hunt-csrf

Performing SSL/TLS Security Assessment

Quick Start

# testssl.sh
testssl.sh https://target.com
# sslyze
sslyze --regular https://target.com

Overview

Assess SSL/TLS server configurations using sslyze, a fast Python-based scanning library. This skill covers evaluating supported protocol versions (SSLv2/3, TLS 1.0-1.3), cipher suite strength, certificate chain validation, HSTS enforcement, OCSP stapling, and scanning for known vulnerabilities including Heartbleed, ROBOT, and session renegotiation weaknesses.

When to Use

• When conducting security assessments that involve performing ssl tls security assessment
• When following incident response procedures for related security events
• When performing scheduled security testing or auditing activities
• When validating security controls through hands-on testing

Prerequisites

• Python 3.9+ with sslyze library (pip install sslyze)
• Network access to target HTTPS servers on port 443
• Understanding of TLS protocol versions and cipher suite classifications

Workflow

Step 1: Configure Server Scan

Create ServerScanRequest with ServerNetworkLocation specifying target hostname and port.

Step 2: Execute TLS Scan

Use sslyze Scanner to queue and execute scans for all TLS check commands concurrently.

Step 3: Analyze Results

Evaluate accepted cipher suites, certificate validity, protocol versions, and vulnerability scan results.

Step 4: Generate Security Report

Produce a JSON report with compliance findings and remediation recommendations.

Output Format

JSON report with supported protocols, accepted cipher suites, certificate details, vulnerability results (Heartbleed, ROBOT), and HSTS status.

Validation Criteria

A successful discovery of this vulnerability class must demonstrate:

• POC reproducible against fresh target instance (timestamp documented)
• Impact scope quantified (data leaked / privilege gained / RCE achieved)
• CVSS or business risk score assigned
• Authorization scope documented (B SRC vs target, A 项目 vs 全量)
• No destructive side effects (if RCE, sandboxed proof preferred)
• Affected endpoint clearly identified with full URL/request

If any of these cannot be demonstrated, treat the finding as inconclusive and run 111-fp-check for cross-verification.

Workflow

1. Recon — Identify the target endpoint via 96-osint-methodology or 009-osint-with-spiderfoot
2. Fingerprint — Confirm component/version using 01-component-nday or Burp Suite passive detection
3. Probe — Send payload variations matching the vulnerability class
4. Verify — Run 111-fp-check to confirm with second tool
5. Document — Fill report template (project-pentest / cnvd-common / edusrc / butian)
6. Submit — Manual submission (never auto-submit)

Tools & Systems

• Burp Suite Pro / Community — Intercepting proxy, scanner, and Repeater for manual testing
• OWASP ZAP — Open-source alternative to Burp with active scanner
• sqlmap — Automated SQL injection detection (for hunt-sqli)
• Nuclei — Template-based vulnerability scanner
• ffuf — Fast web fuzzer for endpoint discovery
• curl / wget — Manual HTTP request crafting
• httpx — HTTP probing and fingerprinting

Run all tools with -rate-limit 20 to avoid OPSEC issues. For deeper investigation, prefer manual testing with Burp over automated scanners (lower false-positive rate).

Advanced Techniques

Chained Vulnerability Exploitation

Combine multiple low-severity findings (open redirect + cookie theft + session hijacking) to demonstrate high-impact chains in reporting.

WAF Evasion Patterns

Use case variations, encoding (URL, double-URL, Unicode), chunked transfer, and parameter pollution to bypass WAF/IDS during testing.