Bulletproof SSL and TLS：Understanding and Deploying SSL TLS and PKI to Secure Servers and Web Applications

目录

1 SSL，TLS和密码学2 协议3 PKI4 针对PKI的攻击5 HTTP和浏览器话题6 实现话题7 针对协议的攻击8 部署9 性能优化10 HSTS、CSP和Pinning11 OpenSSL12 测试OpenSSL13 配置Apache14 配置Java Tomcat15 配置Microsoft Windows和IIS16 配置Nginx17 小结

SSL，TLS和密码学

流式加密（如RC4）本质上依赖于异或？（那么就看它的伪随机序列生成算法了？）同样的key不应使用超过1次——但是这一点实现很难保证吧？Block Ciphers 要求块的长度等于密钥的长度（确定性）对同样的输入总是生成同样的输出最流行的：AES（DES3已被废弃？） Padding（128-bit AES要求输入是16字节对齐的） TLS：最后一个byte包含了填充长度？并且所有的填充字节等于最后一个字节 （密码学）Hash函数 digest（报文摘要）SHA1（建议升级到SHA256） MAC（消息认证码） 必要性：加密可以保证信息不被截获偷看，但不保证被篡改伪造HMAC Block cipher modes（扩展块加密算法处理任意长度输入） ECB：最简单的处理，缺点：密文中可以找到对应明文的相同重复模式 ==> TLS BEAST攻击CBC（SSL主要模式）：IV（随机的‘初始化向量’）——对了，应该在每次会话时产生新的随机数！ 缺点（？）：只能将接受到的数据整体解密？不能从任意位置restart？ GCM（TLS 1.2+）其他： CFBOFBCTR 不对称加密 2048bit RSA等价于112 symmetric bits（#see 密码学强度） 数字签名 首先SHA256 hash ==> 编码hash和附加的元数据 ==> 用私钥加密 => 只有公钥才能解密（解开后可看到元数据和hash）RSA可用于加密和签名DSA和ECDSA只能用于签名（方法不同） 随机数生成 TRNG / PRNG （密码学通信）协议 防御恶意篡改：MAC防御重放攻击：序列号？密钥协商？ 使用PKI认证双方（不过一般只需要认证服务器端吧？客户端可以用普通的post表单密码，但是不能阻止钓鱼攻击窃取密码） 发送随机数，要求对方签名 （会话）密钥交换：Diffie-Hellman 针对密码学的攻击 针对primitive的攻击针对scheme的攻击针对实现的攻击It is often said that cryptography is bypassed, not attacked.强度：对称 vs RSA/DSA/DH vs ECC vs Hash MITM攻击获取访问权 ARP spoofingWPAD hijackingDNS hijackingDNS cache poisoningBGP route hijacking 被动攻击 普适的通信监控视同攻击。支持‘forward secrecy’？#FMM（待找到更多资料） 主动攻击 TLS：Mallory可以让Alice接受一个证书，所需要做的就是愚弄PKI系统...（CA的私钥也有可能被盗）向客户端的浏览器注入漏洞（靠！！！）most likely to be used against individual, high-value targets

协议

RFC 5246：TLS 1.2The best way to learn about TLS is to observe real-life trafficTLS记录 每个记录关联一个64位的序列号（不在网络上发送），两端单独维护，以防御重放攻击opaque data buffer：最长16384B初始不加密，TLS_NULL_WITH_NULL_NULL（握手之前）压缩：HTTP上层已有，CRIME攻击 2012，不安全？可扩展性：代理到子协议 handshake Full握手：4个主要活动：（1）能力交换；（2）证书验证；（3）master私钥达成；（4）验证握手报文没有被第三方修改？ ClientHelloServerHello：每个field只有一个option？Certificate（可选）：服务器的X.509证书链，ASN.1 DER编码；有些使用PGP？ServerKeyExchange：一般不用？ServerHelloDoneClientKeyExchange（强制的）ChangeCipherSpec：不是一个握手消息？OpenSSL 2014不正确的实现 => 不允许握手完成之前发送未认证的alertFinished：PRF（伪随机函数）CertificateRequest：客户端认证请求？CertificateVerify 会话重启：session ID？ RFC 4507，2006；updated by RFC 5077 in 2008 Key Exchange（最有趣的部分） 48-byte master secret shared key目标：生成一个premaster secretTLS支持很多算法：dh_anon dhe_rsa ecdh_anon ecdhe_rsa ecdhe_esdsa krb5 rsa psk dhe_psk rsa_psk srpRSA缺点：允许被动数据采集攻击，一旦知道server私钥（可通过法律强制获取），就可以解密所有数据RSA密钥交换DH密钥交换：对被动攻击是安全的，但是主动攻击可以劫持通信假冒另一方，=> 主要用于认证 利用一个数学上的‘单向函数’domain参数？=> 三重握手攻击 DH参数协商 DHE密钥交换（E=Ephemeral） ECDH密钥交换：理论上静态ECDH是支持的，但实际中只使用ECDHE 服务器本来可以指定一个任意的椭圆曲线，但是TLS里只支持命名曲线 认证* （RSA或ECDSA）加密：3DES、AES、ARIA、CAMELLIA、RC4、SEED MAC-then-encrypt：不安全 认证的加密（AEAD）：不使用padding和块加密，但是使用‘nonce’——最佳实践？ MAC计算不包含padding：padding oracle attacks新的encrypt-then-MAC 重新协商 优点/应用场合：信息隐藏，被动攻击无法观察到客户端的证书（！协商是在加密连接上进行的）动态改变加密强度required场合： Server-Gated CryptoTLS record counter overflow server-initiated：HelloRequest一开始不安全（导致强度降级攻击？），后来增加了一个renegotiation_info扩展 change cipher specapp dataalert 避免truncation攻击（HTTP情况下的connection reset？嗯不太一样） Cipher suites 误解：虽然SHA1对选择前缀攻击有弱点，但用于HMAC-SHA1并无已知攻击 TLS扩展 commonly used：server_name status_request signature_algorithms heartbeat ...应用层协议协商（ALPN）：可以使用默认的HTTP 1.1，也可以是SPDY或HTTP 2.0 vs NPN：某些明文的协议决策载荷，允许路由分流？ 证书透明 SCT（签名的证书时间戳） 椭圆曲线能力：RFC 4492 RFC 7072：+ Brainpool curves，Curve25519当前：2 NIST curves secp256r1/384r1 心跳：用于DTLS（UDP） 2014 OpenSSL实现漏洞，导致服务器Heartbleed NPN 虽然被广泛应用，但没有被TLS工作组接受（！）=> 中间路由设备看不到协商的下一个协议居然是个缺点？？？Fuck Secure RenegotiationServer Name Indication（SNI） 没有这个扩展，一个IP地址只能部署一个证书 Session Tickets*签名算法OCSP Stapling：服务器证书回收？？ 协议限制 允许针对客户端能力的fingerprintinglength hidding？

PKI

PKIX X.509CA/Browser ForumASN.1, BER, DER, and PEM证书Fields证书链 Cross-certification Replying PartiesCAsRevocation CRLOCSP WeaknessesRoot Key CompromiseImprovements

针对PKI的攻击

选择前缀攻击（利用MD5碰撞），RapidSSL，可预测的expire日期和证书序列号DigiNotar：the 1st CA to be completely compromised, and possibly very serious MITM attacks 幸亏有Chrome的专利public key pinning技术检测出OCSP应该交叉检验！Who is ComodoHacker？ the Flame malware（内置sqlite和lua？靠） 微软Terminal Server的漏洞

HTTP和浏览器话题

Sidejacking（流量监视） session tokenmixed contentFiresheep插件：导致好几个high-profile网站完全切换到https Cookie Stealing https下的cookie不应泄露到http，即使是同一域名捕获受害者发送到其他网站的http，然后替换为redirect。。。 改写/操控Cookies攻击 MITM攻击：伪造一个a.www.example.com，然后就可以覆盖www.example.com（！）Mitigation HSTSValidate cookie integrity Chrome 36允许mixed passive content，同时阻塞mixed active content，但是允许ajax。38中将阻塞所有mixed active内容。 Safari不阻塞如何mixed content？？？现在呢？ CSPEV证书 DV证书比较便宜，依赖于简单的基于email的domain name验证由于有人工审查，从没有见过伪造（fraudulent）的EV证书 证书撤销 每个证书在使用之前都应该检查它有没有被撤销Key Issues CRL和OCSP使用序列号来引用证书？？？靠泄露用户隐私？OCSP Stapling允许随证书同时发回OCSP响应信息（how？），不需要用户与CA通信CRL的一个问题是CRL居然由相同的CA负责提供，fuck！这本来应该是由CA之间进行分布式交叉验证的。OCSP 重放攻击响应抑制客户端支持：Chrome改用CRLSets机制

实现话题

SSL证书验证OpenSSL Pulse 2014：可在握手期间注入ChangeCipherSpec，强制协商一个可预测的master secretHostname验证 证书是用ASN.1编码的，字符串有length域，构造一个包含NUL字节的Hostname？？？paypal.com\0.crime.org 随机数生成Heartbleed 可能导致服务器的私钥泄露？？？ 协议降级 SSL 2握手过程没有完整性校验，不提供超过40bits的安全Rollback Protection in SSL 3自愿协议降级* 不过我觉得TLS设计里一方给出cipher suite清单另一方从中选择的思路本身就不正确。理应各自单独给出清单，然后随意选出一个有效的匹配。（也就是说，在cipher suite的确定上引入随机性！）SCSI？ Truncation Attacks close_notify Deployment Weaknesses Virtual Host ConfusionTLS Session Cache Sharing（TLS允许resume'到不同的网站？？）

针对协议的攻击

不安全的重协商 Capture credentials via redirected POST（307？）XSS BEAST TLS 1.0 CBC：IVs可预测，导致CBC降级为ECB；‘已知明文攻击’ client mitigation：1/n-1 split？ Compression Side Channel Attacks CRIME，TIME，BREACH（有点盲机器学习的感觉？仅仅proof of concept） Padding Oracle攻击（skip） 8192个请求恢复1字节明文？需要客户端浏览器注入JS malware RC4 weaknesses Key Scheduling算法Early 1-byte Biases：x ^ 0 = x ？Biases across the first 256 bytesDouble-Byte Biases（只是理论上的） 使用TLS 1.2 GCM：避免TLS 1.0 CBC和RC4的缺陷？？Triple Handshake Attack 黑客完全控制了一个malicious server，那上面有安全证书；ms收到premaster key后打开到目标server的连接，并mirror请求 结果：3方共享相同的master key（注意，这里黑客实际上相当于用合法证书架设了一个https透明代理？）-> unknown key-share 攻击者还不能攻击重协商过程，因为2个连接看到的是不同的verify_data/证书 但是有session resumption机制，这使得握手完成时2个连接上的Finished报文是相同的！（？） Impersonation 注意，重协商之后（之前可以往2端发送任意数据）攻击者将丢失流量可见性（traffic visibility）？ 对于受害者的浏览器来说，只是一个网站？（不对吧）Prerequisites 只能用于网站使用客户端证书的情况（这种情况下才会有重协商过程的发生）其次，必须通过钓鱼，使得受害者愿意将其客户端证书用于攻击者的malicious server Migitation 短期地，客户端可配置为如果重协商后看到不同的服务器证书就断开连接类似地，不接受降低的DH公钥对所有访问都要求客户端证书（这样黑客不大敢明目张胆...）禁用重协商仅启用ECDHE suites Bullrun How can we trust the standards if we don't trust the people who design them？2013，Dual EC DRBG被看作NSA后门

部署

2048-bit RSA相当于112位安全性；256-bit ECDSA相当于128；3072-bit RSA相当于128.密钥管理 用密码加密keyHSM 证书 DV、OV、EV 签名算法 SHA256：Windows XP SP3+，Android 2.3+同时部署SHA1和SHA2？ 证书链撤销选择正确的CA协议配置Cipher Suite配置 Forward Secrecy：有了它每个连接都能单独被保护，否则所有连接都只被一个server key保护（被动攻击） 性能 GCM也是最快的？AES硬件加速？ 互操作性复杂的架构Pinning：high-profile网站指定谁（CA）才能给它签发证书 其他方案：DANE（基于DNSSEC）、Public Key Pinning for HTTP、TACK有没有可能这样做：对HTTP网站，使用JS+WebSocket，完全在应用层实现一个类似于TLS的机制，仅仅用于登陆后敏感信息传递，同时仍然利用http网站提供的证书？称为WebTLS？ HSTS：感觉无非就是对https进行了进一步应用层的增强？CSP

性能优化

TCP优化 初始拥塞窗口调节：# ip route | while read p; do ip route change $p initcwnd 10; donePreventing Slow Start When Idle # sysctl -w net.ipv4.tcp_slow_start_after_idle=0 连接持久性 CDNTLS协议优化 False Start：配合NPN使用？ChaCha20-Poly1305

HSTS、CSP和Pinning

Strict-Transport-Security: max-age=31536000; includeSubDomains HSTS隐私问题：一个HSTS策略可用来存储1bit信息 Content-Security-Policy: default-src 'self'; img-src *; object-src *.cdn.a.com; script-src scripts.a.comCSP默认允许mixed content： Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'; connect-src https: wss Content-Security-Policy: default-src 'self'; report-uri http://a.com/csp-report.cgi 当阻塞访问时报告（开发调试？） Pinning：attack surface reduction（控制你信任的root trust store） 只针对公钥是合理的？证书有时候会重新签发不改变公钥？对允许签名的CA或者网站允许使用的公钥做出白名单限制？HSTS preloaded意味着硬编码某些配置信息到源代码中。。。HPKP vs HSTS DANE 一个新的DNS记录类型：TLSA RR TACK（Trust Assertions for Certificate Keys）CAA（Certification Authority Authorization）

OpenSSL

CSR（证书签名请求）自签名 $ openssl x509 -req -days 365 -in fd.csr -signkey fd.key -out fd.crt 安全地使用HTTP： 对内容进行完整性校验对POST上传的数据进行公钥加密？ 各种格式相互转换：略创建Root CA

测试OpenSSL

本节跳过

配置Apache

配置Java Tomcat

配置Microsoft Windows和IIS

配置Nginx

小结