HTTPS原理
证书
1、证书=Server公钥+申请者与颁发者信息+签名
（CA的公钥公之于众，如浏览器内置，没有在证书中）
2、通过Internet直接传递Server公钥，不安全，易被中间人攻击，故引入有公信力的第三方CA，盖个戳
3、服务端自己生成.csr证书请求文件和.key私钥，公钥可写死在客户端，也可公网从服务端获取证书（公钥）。
4、申请证书不需要提供私钥，提交CSR（包含了公钥和标识名称）,确保私钥永远只能服务器掌握。
5、一个证书可以签发多个域名、泛域名，多个域名共用一个公私钥对
如果是应用服务器（非浏览器）调第三方公网API，证书是怎么解决和校验？
要么应用服务器提前下载导入这个第三方用到的CA根证书，要么服务器忽略证书校验
在公网读写MySQL等数据库，建议开启SSL链路传输加密，校验MySQL服务端需要导入CA根证书到应用服务器，才能连数据库
单向认证
1、源端不做限制，对服务端进行验证，非公司内客户端都可以访问服务端。
2、忽略校验证书，则服务端不可信，有风险。所有不可信的服务端都能访问，易受中间人攻击。
3、严格意义上来说https下不存在中间人攻击，存在中间人攻击的前提条件是没有严格的对证书进行校验，或者人为的信任伪造证书
4、自签的证书，客户端访问时，证书校验error，要么忽略校验，风险见上。要么使用自己定义的信任存储（trust store）代替APP系统自带的，即写死证书/公钥，见6
5、市场上很多APP未做好证书校验，有的只做了部分校验，例如检查证书域名是否匹配证书、是否过期；更多的根本不做校验，于是造成了中间人攻击。此类校验虽然在导入Burp证书到客户端后造成中间人攻击，但攻击门槛已相对较高，对安全要求不是特别高的APP可采用此方法进行防御。
6、为了防止中间人攻击，可以使用SSL-Pinning的技术来反抓包。客户端将预置的证书与从公网接收的证书做比较，如果一致，就建立连接，不走系统的证书信任链去校验，所以即使导入Burp CA公钥证书，也无法进行中间人攻击（抓包）。但相应的成本也会升高，见7
7、如果服务器申请的证书到期(常见)或者因为泄露等其他原因需要更换证书，但这个证书又写死在客户端APP代码中，也就必须强制用户进行客户端升级。对安全有较高要求的app（如金融）用这种。
8、SSL-pinning有两种方式：证书锁定和公钥锁定。
- 证书锁定 （Certificate Pinning）
- 公钥锁定 （Public Key Pinning，推荐）
9、为避免强升的问题，针对6优化。
方案一:推荐公钥锁定，公钥在证书的续期前后都可以保持不变（即密钥对不变）
方案二:动态更新证书。Server生成一对RSA公私钥对，公钥硬编码在APP（证书公钥不用硬编码），私钥放服务器，APP启动的时候，证书信息通过私钥签名发送给客户端，APP用预置的公钥验签，得到证书信息埋入APP设置为锚点。发起https连接获取证书，对比两个证书是否一致进行校验。但效率降低了。
10、抓包只能抓单向认证的
如果是应用服务器（非浏览器）调第三方公网HTTPS接口，证书是怎么解决和校验？
没啥区别，根证书通常是内置在操作系统或者执行环境（如JRE等）中。就像web浏览器一样，为HTTPS请求验证SSL证书（你直接调https接口，不用跳过证书校验，就可以访问）。
在公网读写MySQL等数据库，建议开启SSL链路传输加密，需要导入SSL CA证书到应用服务器，才能连数据库。
双向认证
校验客户端的身份，非授权客户端无法访问指定的服务端
加密协议
等保要求，加密协议用TLS 1.1及以上版本，推荐TLS 1.2
禁止使用TLS1.0、SSL2.0及SSL3.0
HTTPS都加密了什么
- URI路径
- host域名
- cookie头
- header头
- body
针对HTTPS的加密流量分析，是可以获取域名信息的（虽然Host加密了）。因为DNS请求是明文的，如果在三次TLS握手中使用了SNI扩展也是明文传输域名的，但URL(路径和参数)始终是加密的。