HTTPS与SSL

最新推荐文章于 2024-08-18 20:36:52 发布

LEE_MM

最新推荐文章于 2024-08-18 20:36:52 发布

阅读量740

点赞数

分类专栏： php

本文链接：https://blog.csdn.net/qq_21794887/article/details/79607702

版权

php 专栏收录该内容

26 篇文章 0 订阅

订阅专栏

HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版。

SSL：“安全套接层”它是在上世纪90年代中期，由网景公司设计的。互联网上使用的 HTTP 协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改。发明 SSL 协议，就是为了解决这些问题。

因此可以看出 https就是http和 SSL/TLS，就是在http的基础上加上ssl，安全套接层来弥补http的不安全性，并且兼容http现有的特性，后来，ssl不仅仅可以和http合作，还可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化他们的安全性。

SSL/TLS部署最佳实践

1、关于证书

SSL提供的安全质量完全依赖于私钥，私钥是安全证书的基础，而安全证书则是验

证服务器身份的重要因素。

在你的所有服务器上使用2048位的RSA或者等价强度的ECDSA私钥。密钥的长度能
保证在一定时间能的安全，如果你已经使用1024位的RSA，尽量替换它们。如果你

的需求必须使用大于2048位的密钥，请考虑ECDSA，因为性能不错。

私钥是重要的财产，尽可能限制能接触到私钥的人。推荐策略包括：

* 在一台可信的计算机(Shawn注:加固过的物理机器)上生成私钥和CSR(
Certificate Signing Requests)。有一些CA会为你生成密钥和CSR，但这样做
明显不妥。

* 受密码保护的密钥可以阻止在备份系统中被截获

* 在发现被”日”后，撤回老的证书，生成新的密钥和证书。

* 每年更新证书，总是使用最新的私钥。

确保你的证书覆盖到你希望被访问的站点。比如你的主站是www.example.com，但
你可能还有个www.example.net。你的目标就是避免无效证书警告，因为那会让你
的用户产生疑惑从而影响对你的信任。

即使你的服务器只有一个主机名配置，也要记得你不能控制用户是通过什么路径
访问你的站点的，可能是其他的链接过来的。大部分情况下，你应该保证证书能
在没有www前缀的情况下工作(比如，example.com和www.example.com)。所以这里
原则就是：一个安全的WEB服务器应该有一个对所有DNS名称解析正常的证书配置。

通配符证书( WIldcard certificates)有他们的应用场景，但应该避免使用，因

为使用的话意味着暴露给很多人。换句话说，越少的人能访问私钥越好。

选择一个对待安全比较认真的可靠CA( Certificate Authority)，在选择CA过程
中可以考虑以下因素：

* 对待安全的态度

大多的CA都会有常规的安全审计，但是一些会更在意安全一些。搞清楚哪些对
待安全的态度不是一件容易的事情，但一个简单的做法是看看他们在安全方面
的历史状况，他们如何应急被“日”以及如何从错误中学习。

* 实际的市场占有率

* 业务重心

* 提供哪些服务

在最底线的情况，你选择的CA至少应该提供CRL( Certificate List)和OCSP(
Online Certificate Status Protocol)撤回机制以及对于OCSP服务的性能。
CA至少提供域名验证和扩展证书验证功能，最理想的情况可以让你自己选择公
钥算法，今天大多站点都使用RSA，但在未来ECDSA的性能优势可能会变得重要。

* 证书管理选项

如果你的运维环境是需要

* 技术支持

选择一个技术支持不错的CA提供商

2、配置

部署有效的证书：

在很多部署场景中，单一的服务器证书显得不足，而多个证书则需要建立一个信
任链。一个常见的问题是正确的配置了服务器证书但却搞忘了包含其他所需要的
证书。此外，虽然其他证书通常有很长的有效期，但她们也会过期，如果她们过
期就会影响整个链条。你的CA应该提供所有额外需要的证书。

一个无效证书链会导致服务器证书失效和客户端浏览器报警告，这个问题有时候
不是那么容易被检测到，因为有些浏览器可以自己重构一个完整的信任链而有些

则不行。

使用安全的协议：

在SSL/TLS家族中有5种协议：S SLv2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2。
( Shawn注: TLS v1.3还在draft阶段)

* SSL v2不安全，坚决不能用。( Shawn注: OpenSSL和GnuTLS当前的版本
(2014.12.2)不支持SSL v2)

* SSL v3老而且过时，她缺乏一些密钥特性，你不应该使用她除非有特别好的理
由。( Shawn注: POODLE漏洞的出现彻底的废掉了SSLv3，之前很多地方支持
SSLv3的原因是兼容性问题，GnuTLS 3.4中将默认不支持SSLv3)

* TLS v1.0在很大程度上是安全的，至少没有曝光重大的安全漏洞。

* TLS v1.1和TLS v1.2没有著名的安全漏洞曝光。( Shawn注: 由于Edward
Snowden曝光的内容有关于NSA“今天记录，明天解密”的故事，所以大量的自由
软件社区和暗网使者们在过去1年中转向了TLS v1.2的PFS)

TLS v1.2应该成为你的主要协议。这个版本有巨大的优势是因为她有前面的版本
没有的特性。如果你的服务器平台不支持TLS v1.2，做个升级计划吧。如果你的
服务提供商不支持TLS v1.2，要求他们升级。

对于那些老的客户端，你还是需要继续支持TLS v1.0和TLS v1.1。对于临时的解

决方案，这些协议对于大多WEB站点依然被认为是安全。

使用安全的Ciphersuites

要安全的通信，首先得保证你是在和你想要通信的对端在通信。在SSL/TLS里，
ciphersuites是定义你如何安全通信的。她们由一堆多样化的组件组成。如果其
中一个组件被发现是不安全的，你应该切换刀其他的ciphersuites上。

你的目标应该是仅使用提供认证和128位加密或者更强的ciphersuites，其他都应该被排除掉：

* Anonymous Diffie-Hellman( ADH)套装不提供认证
* NULL ciphersuites不提供加密
* 出口密钥交换套装( Export key exchange suites)使用容易被”日“的认证
* 使用强度不够的ciphersuites(比如40或者56位的加密强度)也容易被”日“
* RC4比之前想象的要弱，你应该去除掉，或者计划在未来去掉

* 3DES仅提供108位的安全(或者112位，看具体情况)，这也低于推荐的最低128位。你应该在未来去除她。

控制Ciphersuites选型

在SSL v3和后来的版本里，客户端请求一个她支持的ciphersuites的列表，服务
器就从列表中选择一个去跟客户端做协商。不是所有的服务器都能很好处理这个
过程，一些服务器会选择第一个请求列表中支持的ciphersuite，服务器选择正确

的ciphersuites对于安全而言是极端重要的。

支持Forward Secrecy

Forward Secrecy是一个协议特性，她能开启一个不依赖于服务器私钥的安全会话。
不支持Forward Secrecy的ciphersuites，如果攻击者记录了通信内容，那么她可
以在获得私钥后再解密出来( Shawn注: NSA就在干这件事情，所以看出PFS有多重
要了吧)。你需要优先支持ECDHE套装，可以以DHE套装作为协商回退

（ fallback)的备选方案。

关闭客户端发起的重协商

在SSL/TLS里，重协商允许一方停止交换数据而去重新协商一个安全会话。有一些
场景需要服务器发起重协商的请求，但客户端并没有发起重协商请求的必要。此
外，曾经出现过客户端发起重协商请求的拒绝服务攻击( Shawn注解: 每个重协商

请求服务器的计算量是客户端的15倍)。

降低已知漏洞风险

没有什么是完全安全的，很多防护方案都会随着时间推移成为安全问题。最佳实
践是随时关注信息安全的世界在发生些什么然后采取必要的措施。最简单的是你
应该尽快的打每一个补丁。

下面的一些问题应该引起你的注意：

* 关闭不安全的重协商

重协商特性在2009年时被发现是不安全的，协议需要更新。今天大部分厂商已
经修复，至少提供了一个临时方案。不安全的重协商很危险，因为她很容易被
利用。

* 关闭TLS压缩

2012年，CRIME攻击[6]向我们展示了TLS压缩所导致的信息泄漏可以被攻击者用
于还原部分的敏感数据(比如session cookies)。只有几款客户端支持TLS压缩，
所以即使关掉TLS压缩也不会影响刀用户体验。

* 降低HTTP压缩的信息泄漏风险