网站怎么启用https访问

密，因此，所传送的数据不容易被网络黑客截获和破解。本文介绍HTTPS的三种实现方法

。

方法一 静态超链接

这是目前网站中使用得较多的方法，也最简单。在要求使用SSL进行传输的Web网页链接

中直接标明使用HTTPS协议，以下是指向需要使用SSL的网页的超链接：

<a href=“https://192.168.100.100/ok/securePage.jsp”>SSL例子</a>

需要说明的是，在网页里的超链接如果使用相对路径的话，其默认启用协议与引用该超

链接的网页或资源的传输协议相同，例如在某超链接“https://192.168.100.100/ok/l

ogin.jps”的网页中包含如下两个超链接：

<a href=“./bessl/exam.jsp”>SSL链接</a>

<a href=“http://192.168.100.100/notssl/index.jsp”>非SSL链接

那么，第一个链接使用与“https://192.168.100.100/ok/login.jsp”相同的传输协议

HTTPS，第二个链接使用本身所标识的协议HTTP。

使用静态超链接的好处是容易实现，不需要额外开发。然而，它却不容易维护管理因

为在一个完全使用HTTP协议访问的Web应用里，每个资源都存放在该应用特定根目录下的

各个子目录里，资源的链接路径都使用相对路径，这样做是为了方便应用的迁移并且易

于管理。但假如该应用的某些资源要用到HTTPS协议，引用的链接就必须使用完整的路径

，所以当应用迁移或需要更改URL中所涉及的任何部分如：域名、目录、文件名等，维护

者都需要对每个超链接修改，工作量之大可想而知。再者，如果客户在浏览器地址栏里

手工输入HTTPS协议的资源，那么所有敏感机密数据在传输中就得不到保护，很容易被黑

客截获和篡改！

方法二 资源访问限制

为了保护Web应用中的敏感数据，防止资源的非法访问和保证传输的安全性，Java Serv

let 2.2规范定义了安全约束（Security-Constraint）元件，它用于指定一个或多个We

b资源集的安全约束条件；用户数据约束（User-Data-Constraint）元件是安全约束元件

的子类，它用于指定在客户端和容器之间传输的数据是如何被保护的。用户数据约束元

件还包括了传输保证（Transport-Guarantee）元件，它规定了客户机和服务器之间的通

信必须是以下三种模式之一：None、Integral、Confidential。None表示被指定的Web资

源不需要任何传输保证；Integral表示客户机与服务器之间传送的数据在传送过程中不

会被篡改Confidential表示数据在传送过程中被加密。大多数情况下，Integral或Co

nfidential是使用SSL实现。

这里以BEA的WebLogic Server 6.1为例介绍其实现方法，WebLogic是一个性能卓越的J2

EE服务器，它可以对所管理的Web资源，包括EJB、JSP、Servlet应用程序设置访问控制

条款。假设某个应用建立在Weblogic Server里的/mywebAPP目录下，其中一部分Servle

ts、JSPs要求使用SSL传输，那么可将它们都放在/mywebAPP/sslsource/目录里，然后编

辑/secureAPP/Web-INF/web.xml文件，通过对web.xml的设置可达到对Web用户实现访问

控制。

当Web用户试图通过HTTP访问/sslsource目录下的资源时，Weblogic Server就会查找we

b.xml里的访问约束定义，返回提示信息：Need SSL connection to access this reso

urce。资源访问限制与静态超链接结合使用，不仅继承了静态超链接方法的简单易用性

，而且有效保护了敏感资源数据。然而，这样就会存在一个问题： 假如Web客户使用HT

TP协议访问需要使用SSL的网络资源时看到d出的提示信息: Need SSL connection to

access this resource，大部分人可能都不知道应该用HTTPS去访问该网页，造成的后果

是用户会放弃访问该网页，这是Web应用服务提供商不愿意看到的事情。

方法三 链接重定向

综观目前商业网站资源数据的交互访问，要求严格加密传输的数据只占其中一小部分，

也就是说在一个具体Web应用中需要使用SSL的服务程序只占整体的一小部分。那么，我

们可以从应用开发方面考虑解决方法，对需要使用HTTPS协议的那部分JSPs、Servlets或

EJBs进行处理，使程序本身在接收到访问请求时首先判断该请求使用的协议是否符合本

程序的要求，即来访请求是否使用HTTPS协议，如果不是就将其访问协议重定向为HTTPS

，这样就避免了客户使用HTTP协议访问要求使用HTTPS协议的Web资源时，看到错误提示

信息无所适从的情况，这些处理对Web客户来说是透明的。

实现思想是：首先创建一个类，该类方法可以实现自动引导Web客户的访问请求使用HTT

PS协议，每个要求使用SSL进行传输的Servlets或JSPs在程序开始时调用它进行协议重定

向，最后才进行数据应用处理。

J2EE提供了两种链接重定向机制。第一种机制是RequestDispatcher接口里的forward()

方法。使用MVC(Model-View-Controller)机制的Web应用通常都使用这个方法从Servlet

转移请求到JSP。但这种转向只能是同种协议间的转向，并不能重定向到不同的协议。第

二种机制是使用HTTPServletReponse接口里的sendRedirect()方法，它能使用任何协议

重定向到任何URL，例如：

BeSslResponse.sendRedirect(“https://192.168.100.100/order”)

此外，我们还需使用到Java Servlet API中的两个方法：ServletRequest接口中的getS

cheme()，它用于获取访问请求使用的传输协议；HTTPUtils类中的getRequestUrl()，它

用于获取访问请求的URL，要注意的是该方法在Servlet 2.3中已被移到HTTPServletReq

uest接口。

以下是实现协议重定向的基本步骤：

1. 获取访问的请求所使用的协议；

2. 如果请求协议符合被访问的Servlet所要求的协议，就说明已经使用HTTPS协议了，不

需做任何处理；

3. 如果不符合，使用Servlet所要求的协议(HTTPS)重定向到相同的URL。

例如，某Web用户使用HTTP协议访问要求使用HTTPS协议的资源BeSslServlet，敲入“UR

L：http://192.168.100.100/BeSslServlet”，在执行BeSslServlet时首先使用Proces

sSslServlet．processSsl（）重定向到https://192.168.100.100/BeSslServlet，然后

BeSslServlet与客户浏览器之间就通过HTTPS协议进行数据传输。

以上介绍的仅是最简单的例子，是为了对这种重定向的方法有个初步的认识。假如想真

正在Web应用中实现，还必须考虑如下几个问题：

● 在Web应用中常常会用到GET或Post方法，访问请求的URL中就会带上一些查询字串，

这些字串是使用getRequesUrl()时获取不到的，而且在重定向之后会丢失，所以必须在

重定向之前将它们加入到新的URL里。我们可以使用request.getQueryString()来获取G

ET的查询字串，对于Post的Request参数，可以把它们转换成查询串再进行处理。

● 某些Web应用请求中会使用对象作为其属性，必须在重定向之前将这些属性保存在该

Session中，以便重定向后使用。

● 大多数浏览器会把对同一个主机的不同端口的访问当作对不同的主机进行访问，分用

不同的Session，为了使重定向后保留使用原来的Session，必须对应用服务器的Cookie

域名进行相应的设置。

以上问题均可在程序设计中解决。

通过程序自身实现协议重定向，就可以把要求严格保护的那部分资源与其他普通数据从

逻辑上分开处理，使得要求使用SSL的资源和不需要使用SSL的资源各取所需，避免浪费

网站的系统资源。

原作: https://blog.csdn.net/s003603u/article/details/53907910

该文章内容只是转发

在互联网安全通信方式上，目前用的最多的就是https配合ssl和数字证书来保证传输和认证安全

因此，这三者的关系已经十分清楚了：https依赖一种实现方式，目前通用的是SSL，数字证书是支持这种安全通信的文件。另外有SSL衍生出TLS和WTLS，前者是IEFT将SSL标准化之后产生的（TLS1.0），与SSL差别很小，后者是用于无线环境下的TSL。

我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取。所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

HTTPS其实是由两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

在4.x系统上通过HTTPS进行访问产生如下异常：

Android4.x系统对TLS的支持存在版本差异，具体细节请看以下分析

首先我们查看一下Google关于 SSLEngine 的官方文档说明

这里截取不同Android版本针对于TLS协议的默认配置图如下：

从上图可以得出如下结论：

有了以上关于Android SSLEngine相关知识的铺垫，让我们来测试一下这次目标案例的域名 fort.sports.baofeng.com

我们可以在 QUALYS SSL LABS 测试它对ssl支持的版本

这里截取SSL报告中对我们有用的一部分，如下图

这就能解释为什么大部分4.xAndroid系统在进行HTTPS访问时产生上述异常

我们再次查看SSL报告中的几个关键结果：

从上图可以看出，服务器配置已经可以支持TLS1.0、TLS1.1、TLS1.2

从下图可以看出，Handshake Simulation在Android 4.x系统也可以正常运作了

或许，你以为这样就完美了，但是，你有没有想到过这样一种情况，当你所访问的域名服务器只支持TLS1.2，那Android4.x系统应该如何应对那

答案：想办法让Android4.x打开对TLS1.1、TLS1.2的支持

具体怎么使用HTTPS，参考HttpsUtils：

自行实现SSLSocketFactory ，实现对TLSv1.1、TLSv1.2的支持

---