提高网站安全性：SSL证书与HTTP应用部署总结

为了提高网站安全性，一些比较敏感的页面如注册、登录、控制台等一般都会使用https。 Gmail、网上银行等他们都使用 https 流量。 https/ssl主要起到两个作用：网站认证、内容加密传输、数据一致性。仅信任 CA 颁发的证书进行身份验证，并且所有有效证书均可用于加密流量。 浏览器与SSL证书

上图展示了https协议在IE和Chrome浏览器中的不同表现。 Chrome网站安全指标说明：http://support.google.com/chrome/bin/answer.py?hl=zh&answer=95617 SSL的主要应用是在浏览器和网络服务器之间，但并不限于此。当然，安全性本身就是一个重要的内部功能。但乍一看，部署SSL是为了让用户的浏览器看起来更安全，增加用户的信心。很多企业因此认为是门面，甚至发行机构都卖高价，尤其是国内价格明​​显高于国外价格。 SSL 证书实际上也可以用于客户端身份验证。用户拥有自己独特的证书，可以用来证明自己的身份。当然，不需要用户名和密码。然而，这很少被使用，并且一般的 Web 服务器不支持。加密内容传输更安全。如果只是为了加密，也可以使用自签名证书，但是浏览器无法验证证书，因此会发出非常可怕的警告。因此自签名证书不适合外部使用，只适合内部使用。 ，只需将此证书添加到您的受信任列表或忽略证书验证，以后就不会被捕获。证书必须经过少数主要或辅助 CA 的认证才有效。计算机安全中的信任是一条信任关系链，信任链的顶端称为根证书。自签名证书在技术上是相同的，并且只能用于加密传输。但外部无法信任，所以一般只在内部使用。除了自签名证书不被信任外，如果证书已过期、被吊销，或者证书不代表的域名也不被信任，会导致证书验证错误。网站使用的证书必须受到公众的信任，因此，如果您无法自己签署证书，请请求（购买）一个。 ？

多个域名：仅对多个列出的域名有效。

域名通配符（wildcard）：任何子域名都会显示*.example.com。

注意：SSL 中列出的唯一域名是完全限定域名，子域名算作一个名称，而不是顶级域名。如果您的网站有很多子域名，只需为您实际需要的域名申请证书即可。按验证类型：

• 域名验证：验证域名和网站的所有权。申请验证很简单，只需几分钟。
• 机构验证：为了验证公司信息，必须提交经过认证的域名和公司信息。
• 扩展验证（EV）：这种证书会以“明显”的绿色地址栏显示在浏览器中，给予用户最高级别的信任。有安全评估保证。

个人或小型企业可以使用Type 1或Type 2认证，企业一般使用Type 2认证，少数企业会使用EV认证。 ？年。例如，EV证书和可能显示绿色地址栏的通配符证书更昂贵。国产或代理生产的比国外生产的要贵很多，往往要几千元。它实际上是由可信来源验证的。这与申请证书时类似。使用上没有区别。越贵越好。 3。发行机构（“卖方”）

常见的国外 SSL 提供商有：Thawte、Go Daddy、VeriSign、RapidSSL、GeoTrust (QuickSSL)、StartSSL、Comodo。 StartSSL和GoDaddy相对便宜，GeoTrust和Comodo中等，Thawte和VeriSign较贵。 VeriSign 现归赛门铁克所有，并由天威诚信在中国代理。这是一个小世界。天威诚信位于我多年前的雇主（Venix Star）大楼内。他们的电脑室在一楼。我什至进去过一次。 4。免费的StartSSL 唯一免费的是StartSSL，其他的通常只提供30次免费试用。但是，StartSSL 提供的免费证书属于同一类型。它仅验证域名和电子邮件，不验证组织（这意味着它适用于个人，而不是组织）。不过，验证域名、加密数据就足够了，浏览器也知道，一般人不会看你的证书级别。它适合个人和初创网站。等以后有钱了，就可以要求有偿更换。我成功申请了免费的 StartSSL 证书并将其用于两个子域。最后，证书颁发后，保护私钥证书是最重要的。如果它丢失或泄漏，那就结束了。因为如果被别人使用了就没有安全性了，所以你必须要求证书颁发机构吊销证书并请求新的证书，这当然也需要费用。 规划、配置和设置应用程序这并不意味着拥有 SSL 证书就可以了。我们还需要考虑应用程序的使用问题，这需要规划、服务器配置、应用程序修改等各个方面。 SSL比http消耗更多的CPU资源（主要是在连接建立阶段，然后内容要加密），所以一般网站只是在某些地方使用https，大部分开放内容是不必要的。这取决于具体情况。根据您的业务需求。例如，对于很多安全要求较低的网站来说，根本不使用https也是可以接受的。 某些网站是否同时支持 http 和 https，或者仅支持 https 或强制 https？ 同时支持用户可以使用任意协议访问。用户的请求主要由页面本身上的链接驱动，因为用户通常不会故意自己编辑地址栏。一般来说，我们的网站可以做成同时支持http和https，并且都可以访问。不过这样很容易出现后面提到的混合内容或者混合脚本的问题。您还可以为某些站点安排 https 支持。公共网站一般不使用https。只需将一些链接更改为 https 即可。从专门希望以 https 方式访问的页面引用的绝对 URL 可以使用 https 显式链接。强制使用 https？对于高度安全的网站或网络上的某些页面，可能会强制执行 https 访问。即使用户在地址栏中手动将 https 更改为 http，用户也会自动重定向回 https。例如，您可以配置Web服务器重写规则，自动将这些http URL重定向到相应的https URL（这使得维护更容易），而无需更改应用程序。 修复混合内容问题（http 和 https）混合内容是指：在 https 页面上混合请求非 https 资源，例如图片、css、js 等。如果与其他-https js代码混合，则称为混合脚本。混合内容的危险：如果只混合不安全的图片和css，那么中间人攻击一般只会影响页面浏览，损害会比较小。如果与恶意js代码混合，这种恶意js代码可以完全访问并修改页面上的任何内容，这是非常危险的。另请阅读 Chrome 关于混合脚本危险的说明和提示：尝试删除混合脚本漏洞。因此，只有页面本身和所有链接源都是https的浏览器才被认为是安全的，如果链接了不安全的源（甚至是图片），浏览器会提示不安全，尤其是js。如果浏览器提示不安全，我们就达不到原来的目的了。我们花了很长时间索取 SSL 证书并配置 Web 服务器。到最后，如果因为内容混杂而导致所有的努力都白费了，那可就糟糕了。让我们继续努力，找到一种方法来保证所有链接资源的安全。理论上，混合第三方内容，甚至是第三方 SSL 内容，并不是很好。因为用户信任你，而不是第三方。即使第三方也支持https，你能保证第三方绝对安全吗？不提及任何第三方是绝对安全的，但这太严格了。安全其实是一个权衡问题，需要考虑很多方面。幸运的是，至少浏览器现在认为它是安全的。 引用第三方文件（如CDN分发文件）的问题简单来说，要么提供https支持的第三方有这个问题，要么没有（用你自己本地的）。一般来说，我们会链接到通过CDN分发的文件，例如js库文件，而不是访问我们自己网站上的文件。这样我们就可以利用CDN来加速这个过程，这显然是一件好事。但是，如果我们在页面上使用绝对URL直接链接到这个文件，则不会自动使用https！混合协议内容出现，浏览器又到了“变脸”的时候了。当 SSL 访问 CDN 或其他第三方文件时，会出现一些问题，因为许多 CDN 尚不支持 SSL。如果支持https，则可以直接使用绝对https URL。尽管这是一个同时支持http和https的网站，但也不算太浪费。至少这解决了问题。由于云CDN提供商一般会创建一个单独的子域名供每个CDN用户使用，在这种情况下，如果CDN提供商想要支持https，则必须支持所有可能的子域名，因此CDN提供商必须使用此通配符证书。子域。 相对 URL、绝对 URL 和仅缺少协议的 URL（协议相对 URL）相对路径相对简单，自动匹配用户请求的 http 或 https 协议。但是绝对 URL 是不可能的，因为绝对 URL 有一个明确编写的协议：http://www.example.com/jquery.js。还有另一种方法可以解决这个问题。你一定没见过这种形式： //www.example.com/jquery.js哈哈，一个没有协议的URL（其实还是相对URL），这种形式可以正确使用适当的协议在浏览器中完成！很多人都使用这种方法。然而，有一个小问题。当IE7和IE8处理URL没有日志的CSS文件时，同一个CSS文件会被下载两次。有关详细信息，请参阅史蒂夫的文章。 JS会自动判断当前协议现在我们经常使用js来加载其他js文件或其他文件。如果请求是相对URL，没问题。如果是绝对URL怎么办？事实上，js 脚本可能是这样的： document.location.protocol 评估它是否等于“http:”或“https:”。例如，在 Google Analytics 嵌入代码中： ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics. com /ga.js';如何判断应用程序中的访问协议对于jsp、php等动态页面，还可以动态判断是否使用https协议。因此，应用程序可以根据动态判断生成不同的引用URL。虽然这有些问题，但也算是解决了日志自动识别问题。当然，并不总是需要处理相对路径。例如，在jsp中：

• request.isSecure()为true，表示当前是https，为false，表示http。转到
• request.getScheme() 并返回字符串 https 或 http

请注意，如果 Tomcat 部署在代理后面的其他 Web 服务器上，则必须正确配置它才能返回正确的结果，请参阅最后一部分这篇文章。 同源策略问题最后提醒一下：http和https有不同的起源！就连下面的内容也是一样的。因此，在发出ajax请求时必须使用正确协议的绝对URL。相对 URL ajax 请求并不重要。配置Nginx我们总结一下在Nginx中配置SSL时需要注意的问题。详细的安装和配置内容请参见官方SSL模块、https配置文档等其他资料。 1。首先，检查是否安装了 SSL 模块，因为默认情况下不包含该模块。使用 nginx -V 命令检查。如果ssl模块不存在，需要重新安装（建议更新到最新版本）。安装时注意添加ssl选项：./configure --with-http_ssl_module。另外，nginx必须依赖openssl来提供ssl支持，这也是必需的。 2。 nginx.conf 中的典型配置示例listen 80;listen 443 ssl;ssl_certificate cert.pem; #编辑具体文件ssl_certificate_key ssl.key; #编辑特定文件 ssl_session_cache shared:SSL:10m;ssl_session_timeout 10m ;ssl_protocols SSLv2 SSLv3 TLSv1;ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH_LOWsSL:+PRESERV:+MEDIUM_pre EXFER;开启；上面的 2-4 项是关键。这些配置可以放置在服务器块中，并将反映在其中的所有位置，支持 http 和 https。或者单独配置http和https也是常见的。 3。合并证书配置文件 与Apache配置不同，Nginx需要将服务器证书和ca证书链合并到一个文件中，作为ssl_certificate配置的内容。比如，按照证书链从下到上的顺序，我有三个证书：

1. ssl.crt（有自己域名的服务器证书）
2. sub.class1.server.ca.pem（beginsl 证书） class)
3. ca.pem (根证书开始l)

将它们的内容按顺序连接到一个文件中，每个内容另起一行，内容之间不能有空行或空格。 4。启动时避免输入密码 配置完成后，nginx 需要输入密钥密码才能启动。这是因为ssl_certificate_key配置对应的文件（即beginsl提供给您的私钥文件）的内容是加密的，需要您在创建它时设置的密码才能解密。虽然私钥很安全，但是每次重启服务都需要输入密码，太麻烦了。其实只要把证书改成解密的内容，就可以避免每次都输入密码。只需使用以下命令： openssl rsa -in ssl.key -out newssl.key 输入密码，就会生成解密后的私钥内容。使用这个，你会没事的。但如前所述，您需要在服务器上保护它，例如：chmod 400 ssl.key（只能由 root 读取）5。优化 SSL 配置 SSL 会消耗大量 CPU 资源，尤其是在建立连接的握手阶段时。一种是通过打开 keepalive 来重用连接。其次，ssl session可以复用和共享，参见上面ssl_session相关的配置。 独立的Tomcat+SSLTomcat是一个非常常见的Java应用服务器。当然，它也可以作为独立的Web服务器使用。所有用户都请求直接访问 Tomcat。如果Tomcat作为独立的Web服务器，则必须配置Tomcat。文档可以在这里和这个找到。主要配置keystore和连接器来存储证书。 Java Keystorejava keystore 是一个专门的内置工具，类似于 Java 中的 openssl。 keystore文件是一个“金库”（数据库），专门存储证书和密钥以及相关的管理功能：自签名证书、密钥的生成、导入导出等。交互可以通过 keytool 命令或 Java api 进行。使用keytool命令导入证书。 Tomcat 中的连接器Tomcat 中有三种连接器实现：block、nio 和 APR。前两者使用Java SSL（需要keystore配置），APR使用OpenSSL（不需要使用keystore，直接指定证书），配置略有不同。Nginx+Tomcat+SSL现实中，大型网站由很多Web服务器和应用服务器组成。用户请求在到达应用服务器之前可能会经过 Varnish、HAProxy 和 Nginx。它们之间有好几层。 。中小型部署的典型部署往往是两层配置，例如Nginx+Tomcat，其中使用多个Tomcat和Nginx来进行静态文件处理和负载均衡。如果使用Nginx作为前端代理，Tomcat根本不需要处理https，一切都由Nginx管理。用户首先与Nginx建立连接，并完成SSL连接建立。 Nginx 然后充当代理，使用 http 协议将请求转发给 cat 进行处理。然后 Nginx 加密 cat 输出并通过 SSL 将其发送回用户。这个过程是透明的，Tomcat只处理http。只是一个请求。因此，这种情况下不需要配置Tomcat的SSL，只需要配置SSL和Proxy Nginx即可。 代理模式下的 Tomcat 如何识别直接用户请求（URL、IP、https 或 http）？ 透明代理的情况下，如果不做任何配置，Tomcat会认为所有请求都是Nginx发送的，会导致如下错误结果：

• request.getScheme() //总是http，不是real http 或 https
• request.isSecure() //始终为 false（因为总是 http）
• request.getRemoteAddr() //始终是 nginx 请求 IP，而不是用户
• IP 请求。 getRequestURL() //始终是nginx请求的URL，而不是用户实际请求的URL
• response.sendRedirect(relative url) //总是重定向到http（因为它被认为是http请求）

如果程序在将它们作为实际用户需求处理时遇到问题。解决方案非常简单。只需要分别配置Nginx和Tomcat，无需更改程序。配置 Nginx 转发选项： proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header :两端配置X-Forwarded-Proto是为了正确识别该协议是真实的http用户还是https用户发出的。 X-Forwarded-For是获取用户的真实IP地址。这样，上面的五个测试都会得到正确的结果，就像用户直接访问Tomcat一样。