SSL/TLS高强度加密
由于SSL、HTTP、Apache三者共同对请求进行处理,这使得在支持SSL的web服务器上实现特殊的安全制约变得不那么简单。本节介绍了普通情况下的解决方案,作为找出最终方案的第一步。采用这些方案以前,先要尽量地去理解,不了解其限制和相关性就贸然使用是最糟糕的了。
加密方案和强制性高等级安全
- 仅使用SSLv2的服务器
- 仅接受高强度加密请求的服务器
- 以服务器为网关的加密
- 更强的针对目录的加密需求
如何建立一个仅使用SSLv2的服务器?
可以这样建立一个仅使用SSLv2协议及其密码算法的服务器:
httpd.conf
SSLProtocol -all +SSLv2
SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
如何建立一个仅接受高强度加密请求的SSL服务器?
如下设置为仅使用最强的七种密码算法:
httpd.conf
SSLProtocol all
SSLCipherSuite HIGH:MEDIUM
如何建立一个仅接受高强度加密请求的SSL服务器,而又允许对外浏览器使用更强的加密?
这个功能被称为以服务器为网关的加密(Server Gated Cryptography[SGC]),在随mod_ssl发布的README.GlobalID
文档中有详细说明。简单地说就是:服务器拥有一个由来自Verisign的一个特殊的CA证书签发的服务器身份证,从而在对外浏览器上实现高强度加密。其过程如下:浏览器使用对外密码进行连接,服务器返回其全局ID身份证,浏览器校验后在后继HTTP通讯产生之前提升其密码组。现在的问题是:如何允许这样的提升,而又强制性地使用高强度加密。换句话说就是:浏览器必须在开始连接时就使用高强度加密,或者提升到高强度加密,但是维持对外密码是不允许的。以下巧妙地解决了这个问题:
httpd.conf
# 允许在初始握手阶段使用所有的密码,以允许对外服务器通过SGC功能提升密码组
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
<Directory /usr/local/apache2/htdocs>
# 但是最终会拒绝所有没有提升密码组的浏览器
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
</Directory>
如何建立接受所有类型密码的SSL服务器,但对特定的URL实施高强度加密?
显然,不能使用服务器全局设置SSLCipherSuite
,它会限制密码为强类型。但是,mod_ssl允许重配置针对目录的密码组,并自动进行一个带有服重新配置的SSL参数的重协商。因此,其解决方案成了:
# 在一般情况下的处理是宽松的
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
<Location /strong/area>
# 但对于 https://hostname/strong/area/ 及其以下的内容要求高强度密码
SSLCipherSuite HIGH:MEDIUM
</Location>
客户认证和访问控制
- 简单的基于证书的客户认证
- 选择性的基于证书的客户认证
- 特殊的基于证书的客户认证
- intranet和internet的认证
在知道所有客户的情况下,如何实现基于证书的客户认证?
如果你了解你的用户群体(比如:一个封闭的用户组),正如在一个Intranet中,则可以使用一般的证书认证。所有要做的事情只是,建立由你自己的CA证书签发的客户证书ca.crt
,并依此证书校验客户。
httpd.conf
# 要求客户端必须拥有由我们自己的CA(其证书是ca.crt)直接签名的证书
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt
如何针对一个特定的URL对客户实施基于证书的认证,而同时又允许任何客户访问服务器其余部分?
这又要用到mod_ssl
提供的针对目录的重配置功能:
httpd.conf
SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt
<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
如何针对某些URL对特定的客户实施基于证书的认证,而同时又允许任何客户访问服务器其余部分?
其关键在于对客户证书的各个组成部分进行验证,一般就是指验证 Distinguished Name (DN) 的全部或部分。有基于mod_auth_basic
和基于SSLRequire
类型的两种方法以验证。第一种方法适合用于客户完全属于不同类型,并为所有客户建立了密码数据库的情形;第二种方法适用于客户都属于一个被编码写入DN的公共分级的一部分的情形,因为匹配客户会更容易。
第一种方法:
httpd.conf
SSLVerifyClient none <Directory /usr/local/apache2/htdocs/secure/area>SSLVerifyClient require SSLVerifyDepth 5 SSLCACertificateFile conf/ssl.crt/ca.crt SSLCACertificatePath conf/ssl.crt SSLOptions +FakeBasicAuth SSLRequireSSL AuthName "Snake Oil Authentication" AuthType Basic AuthBasicProvider file AuthUserFile /usr/local/apache2/conf/httpd.passwd require valid-user </Directory>
httpd.passwd
/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
第二种方法:
httpd.conf
SSLVerifyClient none <Directory /usr/local/apache2/htdocs/secure/area>SSLVerifyClient requireSSLVerifyDepth 5SSLCACertificateFile conf/ssl.crt/ca.crtSSLCACertificatePath conf/ssl.crtSSLOptions +FakeBasicAuthSSLRequireSSLSSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} </Directory>
如何要求来自Internet的客户使用强密码的HTTPS,并对其访问Intranet站点的子区域实施或者基本的或者客户证书的认证,而同时又允许Intranet的客户进行普通的HTTP访问?
假设Intranet客户的IP地址是192.160.1.0/24,Intranet站点子区域的URL是/subarea
,则可以在HTTPS虚拟主机以外这样配置(以同时作用于HTTPS和HTTP):
httpd.conf
SSLCACertificateFile conf/ssl.crt/company-ca.crt<Directory /usr/local/apache2/htdocs> # subarea以外的区域只允许来自Intranet的访问 Order deny,allow Deny from all Allow from 192.168.1.0/24 </Directory><Directory /usr/local/apache2/htdocs/subarea> # 在subarea以内,允许所有来自Intranet的访问, # 但对来自Internet的访问,仅允许HTTPS+Strong-Cipher+Password # 或者HTTPS+Strong-Cipher+Client-Certificate# 如果使用了HTTPS,则确保使用高强度加密 # 同时允许客户以基本认证的形式认证 SSLVerifyClient optional SSLVerifyDepth 1 SSLOptions +FakeBasicAuth +StrictRequire SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128# 强制来自Internet的客户使用HTTPS RewriteEngine on RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$ RewriteCond %{HTTPS} !=on RewriteRule .* - [F]# 允许网络访问和基本认证 Satisfy any# 控制网络访问 Order deny,allow Deny from all Allow 192.168.1.0/24# HTTP基本认证 AuthType basic AuthName "Protected Intranet Area" AuthBasicProvider file AuthUserFile conf/protected.passwd Require valid-user </Directory>
SSL/TLS高强度加密相关推荐
- 加密狗原理-高强度加密-程序加密技巧
加密狗原理,加密狗加密的基本原理 本文将介绍软件加密加密狗原理,加密狗加密的基本原理的一些编程技巧,以及软件开发者将如何编写安全可靠 的代码,如何对付各种各样的加密狗破解,编写加密程序时应该尽量避免的 ...
- SSL/TLS、对称加密和非对称加密和TLSv1.3
本文主要对对称加密和非对称加密的原理以及过程进行分析,同时还会简单介绍一下TLS/SSL的一些相关内容,并且对比TLSv1.2和TLSv1.3的不同. 1.SSL和TLS的历史 其实早期的互联网协议基 ...
- 蓝宇风:高强度加密狗
主要产品包括: 金盾加密锁I型,加密强度高,内置专用微处理器芯片(CPU):支持自动跨平台:自带高强度加密算法.低工作电压.低功耗,硬件质量可靠,损坏率低于2‰.适用于软件盗版压力较大且要求较高的性能 ...
- linux 允许ssl采用中强度加密_彻底搞清HTTPS安全通讯之SSL/TLS加密协议
一. 简介 SSL(Secure Socket Layer 安全套接层),由网景在20世纪90年代开发的安全协议: 1995年Netscape发布SSL v2.0 1996年Netscape发布SSL ...
- 高强度文件夹加密大师破解版
"高强度文件夹加密大师"很容易破解! 如下为转述: 很多人用了这个<高强度文件夹加密大师9000>进行了移动加密了重要的工作文件,但是在解密的时候却提示出错,后来上网看 ...
- 常用目录加密的朋友请看:千万别用《高强度文件夹加密大师》这个软件。
晚上妹妹告诉我说,她有一些相片用了<高强度文件夹加密大师>这个软件在电脑上面加密了,但是不知道为什么不能解密了,密码试了很多次,一开始,她怀疑是密码错误,试着用软件解密了很多次,还是不管用 ...
- HTTPS安全通讯 2. SSL/TLS加密协议
HTTPS安全通讯 2. SSL/TLS加密协议 一. 概述 1. SSL 2. `OpenSSL` 3. `https` 4. 密钥协商算法 1.4.1 RSA算法 1.4.2 DH算法 5. 前向 ...
- 简单了解SSL/TLS协议
今天小编就为大家带来一篇关于SSL/TLS协议的文章.小编觉得挺不错的,为此分享给大家做个参考.一起跟随小编过来看看吧. TLS名为传输层安全协议(Transport Layer Protocol) ...
- SSL/TLS安全:Schannel中WinShock漏洞及解决办法
Schannel是最新被发现存在SSL/TLS安全问题的加密库,在过去一年中SSL/TLS协议出于各种错误的塬因占据着新闻头条.苹果的SecureTransport.OpenSSL.GnuTLS和Mo ...
最新文章
- 这回导师们颤抖了,这个网站能匿名评价其“人品”,已有大量“不良”导师被爆...
- Anaconda conda常用命令
- hadoop题目(一)
- python中文分词jieba总结
- 网站维护页面_营销型企业网站有哪些功能?
- c语言 三个小球排排坐,关颖三个孩子排排坐 太萌啦
- Linux面试题100道
- Gtk的entry传递数据到内部程序
- ad 单点登录 java 访问权限_如何配置Portal 基于AD的单点登录配置
- 23种设计模式(八)对象创建之抽象工厂
- 5G学习之路——认识CU、DU
- 主动扫描技术nmap详解
- Qt 网络聊天室项目
- Hybrid App(混合模式移动应用)
- Python HTTP代理的优缺点?芝麻代理豌豆代理熊猫代理讯代理?
- Webservice接口与HTTP接口学习笔记。
- centos7安装字体
- CDR插件开发之CPG插件001 - 什么是CPG插件
- vue中的百度地图的搜索定位功能
- winbox添加dhcp和nat