君，已阅读到文档的结尾了呢~~
SSL协议的分析和应用,ssl协议,ssl协议详解,ssl 协议出错,什么是ssl协议,图解ssl tls协议,应用层协议,应用层协议有哪些,网络协议分析,协议分析
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
SSL协议的分析和应用
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口WEB应用中使用SSL的三种实现方法
Internet的迅猛发展，信息的快速通达使得企业拥有了一个商机无限的广阔发展空间，由于互联网是一个完全开放的网络，使得在其上传输的各种数据面临种种被窃听和丢失的危险。目前在互联网上很多Web应用，尤其是那些电子商务应用，如网上银行，网上超市，股票和债券的在线交易以及软件的付费下载等，都需要在Web服务器和客户端浏览器之间传输机密敏感数据，这些数据包括了信用卡号，密码，银行帐号等高度私隐数据，如果这些数据给别人截获或篡改就会对客户和网站造成不可估量的损失。
为了保护这些敏感数据在传送过程中的安全，全球许多知名企业采用SSL（Secure Socket Layer）的加密机制。
SSL是Netscape公司所提出來的安全保密协议，在浏览器（比如Internet Explorer、Netscape
Navigator）和WWW服务器（如Netscape的Netscape Enterprise Server 、ColdFusion
Server等等）之间构造的安全通道来进行数据传输，SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，它采用了RC4、MD5，以及RSA等加密演算法，使用40
位的密钥，合适与对于商业信息的加密。同时，Netscape公司相应开发了HTTPS协议并内置于其浏览器中，HTTPS实际上就是SSL
HTTP，它使用默认端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。HTTPS协议使用SSL在发送方把原始数据进行加密，然后在接受方进行解密，加密和解密需要发送方和接受方通过交换共知的密钥来实现，因此，所传送的数据不容易被网络黑客截获和解密。
然而，加密和解密过程需要耗费系统大量的开销，严重降低机器的性能，有关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。假如为了安全保密，将一个网站所有的Web应用都启用SSL技术来加密，并使用HTTPS协议进行传输，那么该网站的性能和效率将会大大降低，而且没有这个必要，因为一般来说并不是所有数据都要求那么高的安全保密级别，所以，我们只需对那些涉及敏感机密数据的交互处理使用HTTPS协议，这样就做到鱼与熊掌兼得。下面由简单到复杂分步介绍三种具体实现方法
方法一、静态超链接，
这是目前网站中使用得比较多的做法，也是相对最简单的。我们在要求使用SSL进行传输的WEB应用或网页的链接中直接标明使用HTTPS协议，以下是指向需要使用SSL的网页的超链接：
href=”https://192.168.100.100/ok/securePage.jsp”&SSL例子&/a&
需要说明一下的是，在网页里的超链假如使用相对路径的话，其默认启用协议与引用该超链的网页或资源的传输协议相同，例如在某超链https://192.168.100.100/ok/login.jps的网页中包含如下两个超链：
href=”./bessl/exam.jsp”&SSL链接&/a&
href=”http://192.168.100.100/notssl/index.jsp”&非SSL链接&/a&
那么，第一个链接使用和https://192.168.100.100/ok/login.jps相同传输协议https，第二个链接使用本身所标识协议http。
使用静态超链的方法，好处是很容易实现，不需要额外的开发工作。然而，容易实现并不等于容易维护管理。因为在一个完全使用http协议访问的Web应用里，每个资源都存放在该应用所特定根目录下的各个子目录里，资源的链接路径都使用相对路径，这样做是为了方便应用的迁移并且易于管理。但假如，该应用某些资源要用到https协议的话引用的链界就必须使用完整的路径，所以当应用迁移或需要更改URL中所涉及的任何部分如：域名，目录，文件名等，维护者都需要每个超链的改，工作量之大可想而知。再者，使用静态链的存在一个很大的问题，如果客户在浏览器URL里手工输入使用http协议访问要求使用https协议的资源，那么所有敏感机密数据在传输中就会得不到保护，很容易被黑客截获和篡改！
方法二、资源访问限制
为了保护WEB应用中的敏感数据，防止资源的非法访问和保证传输的安全性，JAVA Servlet
2.2规范定义了security-constraint（安全约束）元件，它用于指定一个或多个WEB资源集的安全约束条件；user-data-constraint（用户数据约束）元件是security-constraint元件的子类，它用于指定在客户端和容器之间传输的数据是如何被保护的。user-data-constraint元件还包括了transport-guarantee（传输保证）元件，它规定了客户机和服务器之间的通讯必须是以下三种模式之一：NONE、INTEGRAL、CONFIDENTIAL。NONE表示被指定的Web资源不需要任何传输保证；INTEGRAL表示客户机服务器之间传送的数据在传送过程中不会被篡改；CONFIDENTIAL表示数据在传送过程中不被篡改和获得。大多数情况下，INTEGRAL
或CONFIDENTIAL是使用SSL(Security Socket Layer)加密套接字协议层来实现的。
这里以BEA的WebLogic Server
6.1为例介绍其实现方法，WEBLOGIC是一个性能卓越的J2EE服务器，它可以对所管理的WEB资源，包括EJB、JSP（JavaServer
Page）、SERVLET应用程序设置访问控制条款，这里只介绍对WEB用户实现访问控制的做法。假设我们手头上有某应用建立在weblogic
server里的/mywebAPP目录，其中一部分servlets、JSPs是要求使用SSL传输的，那么我们就将它们都放在/mywebAPP/sslsource/目录里。接下来，我们编辑/secureAPP/WEB-INF/web.xml文件，通过对web.xml的设置可达到对WEB用户实现访问控制的目的。以下是个web.xml文件的例子：
&security-constraint&
&web-resource-collection&
&web-resource-name&SecureAPP&/web-resource-name&
&description&App using
https&/description&
&url-pattern&/ sslsource
String desiredScheme = HTTPS;
String usingScheme =
userRequest.getScheme();
String redirectString =
!desiredScheme.equals(usingScheme)) {
StringBuffer url =
HttpUtils.getRequestURL(userRequest);
url.replace(0, usingScheme.length(),
desiredScheme );
redirectString =
url.toString();
if( redirectString != null ){
ourResponse.sendRedirect(
ourResponse.encodeRedirectURL(redirectString));
}catch(Exception ioe){
例如，某WEB用户使用http协议访问要求使用https协议的资源BeSslServlet，敲入URL：http://192.168.100.100/BeSslServlet，我们在执行BeSslServlet时首先使用ProcessSslServlet．processSsl（）进行重定向到：https://192.168.100.100/BeSslServlet，然后
BeSslServlet与客户浏览器之间就通过https协议进行数据传输。
以上介绍的仅是一个最简单的例子，该例子是为了让我们对这种重定向的方法有个初步的认识和概念。假如要真正在WEB应用中实现起来，我们还必须考虑如下几个问题：
在WEB应用中常常会用到GET或Post方法，访问请求的URL中就会带上一些查询字串，这些字串是我们使用getRequesUrl()所获取不到的，而且在重定向之后会丢失，所以必须在重定向之前将它们加入新的URL里。我们可以使用request.getQueryString()来获取GET的查询字串，对于Post的Request参数，我们可以把他们转换成查询串再进行处理。
某些WEB应用的请求中会使用到对象来作为其属性，我们必须在重定向之前将这些属性保存在该session中，以便重定向后使用。
大多数浏览器会把对同一个主机使用不同端口访问当作对不同的主机访问一样，分用不同的session，为了使重定向后保留使用原来的session，我们必须对应用服务器的cookie
域名中进行相应设置。
以上的问题均可在程序设计中解决，这里就不细说。
通过程序自身实现协议重定向，我们就可以把要求严格保护的那部分资源与其他普通数据从逻辑上分开处理，使得要求使用SSL的资源和不需要使用SSL的资源各取所需，避免浪费网站的系统资源，提高了网站的工作效率，又加强了对敏感数据的传输保护。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。SSL证书与Https应用部署小结
- hzp - ITeye技术网站
博客分类：
为了提高网站的安全性，一般会在比较敏感的部分页面采用https传输，https/ssl 主要起到两个作用：网站认证、内容加密传输和数据一致性。经CA签发的证书才起到认证可信的作用，所有有效证书均可以起到加密传输的作用。
按证书包含域名数量分为：
单域名：只针对这个域名有效，不能用在其它域名下。
多域名：只针对列出的多个域名有效。
通配符域名(wildcard)：对任意子域名有小，显示的是 *.。
注意：SSL所说的单个域名是一个完整的域名，一个子域名就算一个，而非一个顶级域名。
如果网站有很多子域名，只需要申请真正需要的域名证书。
按验证的类别分：
域名认证（Domain Validation）：认证你的域名所有权和网站，申请验证简单，几分钟即可。
组织机构认证（Organization Validation）：认证的域名和公司信息，需要提交公司资料认证。
扩展认证（Extended Validation，简称EV）：这种证书会在浏览器中出现“很明显”的绿色地址栏，给用户的可信度最高。有安全评估保证。
Nginx 配置SSL
小结一下 Nginx 配置SSL注意的问题，详细安装配置内容请参考其它资料，如官方
1. 首先检查一下是否已安装了 SSL模块，因为默认是不包含的。
用 nginx -V 命令检查一下。如果没有ssl模块则需要重新安装（建议升级到最新版本），注意安装时加上ssl 选项：
./configure --with-http_ssl_module
另外，nginx需要依赖 openssl 提供ssl支持，这个也要有。
2. nginx.conf 中的典型配置示例
ssl_certificate
cert. #修改具体文件
ssl_certificate_key
ssl. #修改具体文件
ssl_session_cache
shared:SSL:10m;
ssl_session_timeout
ssl_protocols
SSLv2 SSLv3 TLSv1;
ssl_ciphers
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_
上面第2-4项是关键。这些配置放在 server 块就可以对其中的所有 location 生效了，并且同时支持 http 和 https 。或者把 http 和 https 分开配置也很常见。
3. 合并证书配置文件
和Apache配置不同，Nginx需要将服务器证书和ca证书链合并到一个文件中，作为 ssl_certificate 配置的内容。
例如，按照证书链从下向上的顺序，我有三个证书：
ssl.crt（自己域名的服务器证书）
sub.class1.server.ca.pem（startssl 的一类证书）
ca.pem（startssl 的根证书）
把它们的内容按顺序连接到的一个文件中，每个内容另起一行，中间没有空行或空格。
4. 避免启动时输入密码
配好之后，启动nginx 要你输入密钥的密码。这是因为 ssl_certificate_key 配置对应的文件（也就是 startssl 给你的私钥文件）内容是加密的，需要输入你创建这个时设置的密码才能解密。这样私钥虽然很安全，但是每次重启服务都要输入一次密码也太麻烦了。其实，只要证书改为解密了的内容，就可以避免每次输入密码。用如下命令即可：
openssl rsa -in ssl.key -out newssl.key
输入密码，就生成了解密后的私钥内容，使用这个就OK了。
但是就像前面说的，一定要在服务器上保护好它，例如：
chmod 400 ssl.key （仅root可读）
5. 优化SSL配置
SSL 很消耗 CPU 资源，尤其是在建立连接的握手阶段。一是通过开启 keepalive 可以重用连接。二是可以重用和共享ssl session，见上面ssl_session相关配置。
独立Tomcat+SSL
Tomcat 是很常见的 Java应用服务器，当然也可以作为独立的 Web服务器，所有用户请求直接访问 tomcat。
如果 Tomcat 作为独立的Web服务器，那么就需要配置Tomcat就可以了，文档参考 和 。主要是配置存放证书的 Keystore 和 连接器Connector。
Java的keystore
keystore 是 Java 中专用并内置的一个类似于 openssl 的工具，一个 keystore 文件就是一个“保险箱”（database），专门存放证书和密钥，和相关的管理功能：生成自签发的证书、密钥、导入导出等。可以通过 keytool 命令或 Java api 交互。
利用keytool 命令将你的证书导入进去。
Tomcat中Connector
tomcat中有三种 Connector 实现：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 协议将请求转给 tomcat 处理，Nginx再把 tomcat 的输出通过SSL 加密发回给用户，这中间是透明的，Tomcat只是在处理 http 请求而已。因此，这种情况下不需要配置 Tomcat 的SSL，只需要配置 Nginx 的SSL 和 Proxy。
在代理模式下，Tomcat 如何识别用户的直接请求（URL、IP、https还是http )？
在透明代理下，如果不做任何配置Tomcat 认为所有的请求都是 Nginx 发出来的，这样会导致如下的错误结果：
request.getScheme()
//总是 http，而不是实际的http或https
request.isSecure()
//总是false（因为总是http）
request.getRemoteAddr()
//总是 nginx 请求的 IP，而不是用户的IP
request.getRequestURL()
//总是 nginx 请求的URL 而不是用户实际请求的 URL
response.sendRedirect( 相对url )
//总是重定向到 http 上 （因为认为当前是 http 请求）
如果程序中把这些当实际用户请求做处理就有问题了。解决方法很简单，只需要分别配置一下 Nginx 和 Tomcat 就好了，而不用改程序。
配置 Nginx 的转发选项：
proxy_set_header
proxy_set_header
proxy_set_header
X-Forwarded-For $proxy_add_x_forwarded_
proxy_set_header X-Forwarded-Proto
配置Tomcat server.xml 的 Engine 模块下配置一个 Value：
&Valve className="org.apache.catalina.valves.RemoteIpValve" remoteIpHeader="X-Forwarded-For"protocolHeader="X-Forwarded-Proto" protocolHeaderHttpsValue="https"/&
配置双方的 X-Forwarded-Proto 就是为了正确地识别实际用户发出的协议是 http 还是 https。X-Forwarded-For 是为了获得实际用户的 IP。
这样以上5项测试就都变为正确的结果了，就像用户在直接访问 Tomcat 一样。
浏览: 156371 次
来自: 广州
功能真强大
你好，请问你用的extjs什么版本，2.2能使用吗
还是例子看着清晰，谢谢SSL的工作原理以及对称加密的应用范围
在客户端与服务器间传输的数据是通过使用对称算法（如 DES 或 RC4）进行加密的。公用密钥算法（通常为
RSA）是用来获得加密密钥交换和数字签名的，此算法使用服务器的SSL数字证书中的公用密钥。有了服务器的SSL数字证书，客户端也可以验证服务器的身份。SSL
协议的版本 1 和 2 只提供服务器认证。版本 3 添加了客户端认证，此认证同时需要客户端和服务器的数字证书。 　　
　　SSL 连接总是由客户端启动的。在SSL 会话开始时执行 SSL 握手。此握手产生会话的密码参数。关于如何处理 SSL
握手的简单概述，如下图所示。此示例假设已在 Web 浏览器 和 Web 服务器间建立了 SSL 连接。
　　图 SSL的客户端与服务器端的认证握手
&(1) 客户端发送列出客户端密码能力的客户端“您好”消息（以客户端首选项顺序排序），如 SSL
的版本、客户端支持的密码对和客户端支持的数据压缩方法。消息也包含 28 字节的随机数。
服务器以服务器“您好”消息响应，此消息包含密码方法（密码对）和由服务器选择的数据压缩方法，以及会话标识和另一个随机数。
　　注意:客户端和服务器至少必须支持一个公共密码对，否则握手失败。服务器一般选择最大的公共密码对。
　　(3) 服务器发送其SSL数字证书。（服务器使用带有 SSL 的 X.509 V3 数字证书。）
　　如果服务器使用 SSL V3，而服务器应用程序（如 Web
服务器）需要数字证书进行客户端认证，则客户端会发出“数字证书请求”消息。在
“数字证书请求”消息中，服务器发出支持的客户端数字证书类型的列表和可接受的CA的名称。
　　(4) 服务器发出服务器“您好完成”消息并等待客户端响应。
　　(5) 一接到服务器“您好完成”消息，客户端（ Web
浏览器）将验证服务器的SSL数字证书的有效性并检查服务器的“你好”消息参数是否可以接受。
　　如果服务器请求客户端数字证书，客户端将发送其数字证书；或者，如果没有合适的数字证书是可用的，客户端将发送“没有数字证书”警告。此警告仅仅是警告而已，但如果客户端数字证书认证是强制性的话，服务器应用程序将会使会话失败。
　　(6) 客户端发送“客户端密钥交换”消息。此消息包含 pre-master secret （一个用在对称加密密钥生成中的
46 字节的随机数字），和 消息认证代码 （ MAC ）密钥（用服务器的公用密钥加密的）。
　　如果客户端发送客户端数字证书给服务器，客户端将发出签有客户端的专用密钥的“数字证书验证”消息。通过验证此消息的签名，服务器可以显示验证客户端数字证书的所有权。
　　注意: 如果服务器没有属于数字证书的专用密钥，它将无法解密 pre-master
密码，也无法创建对称加密算法的正确密钥，且握手将失败。
　　(7) 客户端使用一系列加密运算将 pre-master secret 转化为 master secret
，其中将派生出所有用于加密和消息认证的密钥。然后，客户端发出“更改密码规范”
消息将服务器转换为新协商的密码对。客户端发出的下一个消息（“未完成”的消息）为用此密码方法和密钥加密的第一条消息。
　　(8) 服务器以自己的“更改密码规范”和“已完成”消息响应。
　　(9) SSL 握手结束，且可以发送加密的应用程序数据。
SSL协议的应用:
　　SSL协议综合了私有密钥加密法、公开密钥加密法、数字签名和数字证书等多种安全保障手段，并且几乎所有操作平台上的Web浏览器（如IE，Navigator）以及流行的Web服务器（IIS，Netscape
En?鄄terprise
Server）都支持SSL协议。因此，SSL协议便宜，开发成本小，应用简单方便，其安全性也不错，速度上比较快。
　　SSL协议首先被应用在网络支付中，目前国内外流行的信用卡网络支付、网络银行服务等都可构建在SSL之上。中国的招商银行、工商银行北京分行等信用卡网络支付均采用了SSL协议机制。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。