博客访问： 738870
博文数量： 232
博客积分： 50
博客等级： 民兵
技术积分： 3948
注册时间：
iihero@ChinaUnix, ehero.[iihero]
数据库技术的痴迷爱好者.
您可以通过iihero 联系到我
以下是我的三本图书:
Sybase ASE in Action,
Oracle Spatial及OCI高级编程,
Java2网络协议内幕
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： C/C++
现在，很多网站或者服务，都实现成基于SSL，并且提供证书下载安装才能访问。如果它能提供下载，当然什么问题有没有。
可是，如果你无权下载，并且它不是CA证书，只是自签名的Server端证书。只知道它的端口和地址，你强行通过程序访问，可能会得到这样的错误：
没想到，Sun提供了一个工具程序，能够能过程序调用，得到Server端的证书。
这里以12306某部分购票需要证书为例：
这样，把这个证书都可以导出来：
导成可见文本：(密码是默认的changeit)
这样，你随时可以用上边的证书建立到目标主机的SSL连接。
阅读(1339) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。抽了点时间研究了下KTLS，这源自于跟同事交流的一个问题，那就是现如今的HTTPS服务器以及scp命令传输本地文件的时候，无法使用sendfile系统调用！&&&&&&& 这个话题让我想起了很多的老同事，为了不骚扰到他们，本文中我一律使用只有我们自己才知道的昵称。&&&&&&& 我后悔当初为什么没有想到一个让HTTPS/scp支持sendfile/splice/tee调用族的方案，我表示后悔是因为这乃是比OpenVPN更加能体现业界影响力以及个人价值的途径，不管是对公司还是对个人，都将是价值无限的。并且，这是一个融合了系统调用，网络技术，加密解密技术于一体的方向。&&&&&&& 我在2010年初经历了第二次迷茫之后的一年，苦苦寻求方向，在我一头扎进半瓶子的OpenVPN细节以及一知半解地搞定的原始版国标ECC加密算法与OpenSSL的融合之后，我选择了OpenVPN，之后我等于说再也没有在SSL协议方面有所突破，一去就是四五年！我本来可以做一个类似AF_KTLS的东西的，但是一次又一次的与之擦肩而过，直到现在，我已经离开了原来的公司，并且甚至都不再做任何与SSL/TLS以及PKI相关的事情，却突然让我知道了有一个来自Facebook现成的方案，这已经到了2016年！Facebook的方案来自2015年，其实我们可以更早的，但是没有，所以我表示非常悔恨！我之所以这么说，是因为几乎不用你仔细想就能Step by step跟上Dave Watson的思路，一切都显得那么自然和直接，就像KTLS是一个理所当然的方案一样，我曾经发表过《OpenVPN的Linux内核版，鬼魅的残缺》这一系列文章，并且做了相同的事，但是差那么一点，如果我当时不是在优化VPN，而是在优化正向代理或者反向代理，或者在优化HTTPS服务器本身，那么我认为移进内核的应该就是TLS记录协议了。我摘录一句来自文章《》的话：1.内核模块：运行一个内核模式的TCP服务器，收到数据后按照数据包的第一个字节的值区分是控制通道数据还是数据通道数据，如果是控制通道数据，则通过一个字符设备路由给用户态的一个进程，如果是数据通道数据，则直接在内核处理；那是在2014年！&&&&&&& 另外一个插曲那就是，在2010年，我并不知道OpenVPN有自己的封装协议，我一直以为OpenVPN就是用SSL记录协议来封装数据的，这显然是最初对OpenVPN的错误认知，但如果我一直错下去并一直错到2014年往内核移植数据通道处理逻辑时，我依然也会把TLS记录协议扔进内核。虽然，我使用了Netfilter模块机制而不是socket机制...&&&&&&& 正文之前，煽点情吧，温州皮鞋厂老板，王姐姐，小雨，小群群，木经理，主音吉他手，华叔...唉，九味杂陈啊...&&&&&&& 另外，KTLS已经出来一年多了，网上的资源非常有限，除了google可以搜到的几个patch就是来自Dave Watson的github本身了，中文社区几乎没有讨论这个的，百度搜索的结果更是渺渺，所以我写了这篇文章，就像关于TCP BBR和TCP CDG的科普文章一般，我感觉我又一次占了沙发。&&&&&&& 以上乃例行感慨，没有感慨是不成文的，每一篇文章都是情感的迸发，再加上半夜起来发现天有下雨，就不再睡了，我本人是比较喜欢下雨的。-----------------------------------我们知道，sendfile可以让文件系统直接和另一个文件系统通信，用通信网络的术语来讲，用户程序仅仅处在控制平面，数据平面完全在内核中进行，这样可以避免内存拷贝以及各种切换，从而大大提高性能。一般的WEB服务器或者文件服务器都是采用sendfile来将一个文件直接发送到一个socket的，但是对于HTTPS，这样不行，因为内核中无法处理加密，你总是要把数据拉到用户态，将其加密，然后再封装成TLS记录协议，然后再Write到socket...&&&&&&& 且慢！不是有AF_ALG socket吗？不错，这正是本文的内容之一，现在还不是时候详解。&&&&&&& 不光HTTPS，就连系统开发或者运维人员平日非常常用SSH套件中scp，也无法使用sendfile，理由同上！我们可以从下面的图中看出究竟。同样的思路，请看一个关于在BSD系统优化HTTPS的介绍《》。但是本文无意详述sendfile/splice/tee这个系统调用族，这些只是一个引子，我想就这个引子展开针对内核态TLS的讨论。本文的结构大致如下：0.例行的感慨1.介绍KTLS的原理2.介绍如何把Dave的例子跑通3.对KTLS简单的进行评价4.另外一种替代的方案-----------------------------------这次是Facebook带来了福音，参见《》，来自Facebook的Dave Watson引入了一个新型的socket，即AF_KTLS，它可以附着在一个TCP/UDP套接字上在内核态直接加密并且做TLS封装，其框架如下图所示：按照作者所述，TLS握手逻辑还是在用户态完成，这个握手协议事实上是控制平面的事情。在AF_KTLS socket中，除了完成加密/解密以及记录协议封装/解封装之外，其它操作全部都由其附着于其上的TCP/UDP socket来完成，因此AF_KTLS socket暴露给用户态的接口就跟标准的AF_INET socket的TCP/UDP套接字一样，你当然可以通过sendfile给它发送文件！&&&&&&& 原理就介绍到这里，非常简单！复杂的东西在于加密，解密，HMAC那些操作，这方面我不是专家，在PKI公司混迹了5年有余也只是略懂，所以说就不在这里装逼了。温州老板号称比我懂的多，但也只是号称，王姐姐那是真懂。-----------------------------------下面我们来看一下如何让Dave的例子跑起来。1.KTLS源码下载我们从KTLS的github上把源码Downlaod下来，并且编译，其地址如下：2.编译和加载这个步骤我分为以下几个步骤，对于熟悉的人来讲，超级简单。2.1.选择内核版本我选择的是最新的Linux 4.9的内核，正好现在搞BBR算法，也是用的这个内核。估计忙完这一阵子，我要跟2.6.32内核告别了。2.2.打补丁并重启到新内核进入4.9内核根目录，直接执行patch -p1 &$rfc5288.patch的路径即可，然后例行地make all -j20 && make modules_install && make install即可。编译成功后重启到新内核，并且安排好新的4.9内核头文件路径，准备编译模块。2.3.编译内核模块此时开始编译af_ktls.c，直接make即可，skb_splice_bits这个函数的参数会报too many，按照4.9的内核fix掉即可。然后加载编译生成的af_ktls.ko。3.KTLS实例下载Dave顺便写了一个非常简单的使用KTLS进行记录协议封装的例子，基于OpenSSL的。这个例子的结构非常简单：Server Thread：运行一个基于OpenSSL的服务端，在一个循环中调用SSL_write/SSL_read进行数据的读写，并输出结果；Client Thread：运行一个基于OpenSSL的客户端，首先使用标准的SSL_read/SSL_write进行数据读写，然后调用AF_ALG socket进行数据读写，并在Server Thread观测输出的结果。注意：Dave的Demo就是使用的AF_ALG socket而不是AF_KTLS，起初我已经他搞错了，后来发现这是两个版本。&&&&&&& 它内建了一个TLS服务端和一个TLS客户端，TLS客户端与TLS服务端成功完成TLS握手之后，客户端将用标准的OpenSSL调用SSL_read/SSL_write以及KTLS socket的send/recv/sendfile两种方式与服务端通信，旨在证明这两种方式的效果是等同的，从而就可以说明KTLS实现与OpenSSL的协议兼容性。其github地址如下：。照例我们应该把它下载到本地并编译运行。-----------------------------------然而，遗憾的是，这个例子并非针对上述AF_KTLS socket实现的，而是针对另一个基于AF_ALG socket的等效机制的(algif_tls patch，后面会谈)。我不知道Dave为什么重新基于AF_KTLS再Fork一个该Demo，虽然针对AF_KTLS基于OpenSSL的例子没有完成，但是Dave基于GUNTLS完成了一个更加正式的例子，它的地址如下：。通过编译运行这个例子，你会发现KTLS确实是正确的且高效的。然而，我相信还是熟悉OpenSSL的比熟悉GNUTLS的要多。并且，ktls这个例子非常简单，就一个C文件，这种风格是我最喜欢的，简单清晰，不必陷入代码结构，语言以及工具的细节，所以说，我想完成上面那个基于OpenSSL的测试AF_KTLS的例子。&&&&&&& 后来我花了点时间，终于把Dave的那个测试algif_tls的例子改成了测试AF_KTLS的例子并且调通了，并Fork了出来，地址在：。&&&&&&& 调试的过程非常乏味，主要就是“如何从OpenSSL的EVP_AES_GCM_CTX结构中取出Key，IV以及Salt问题”，这些都是在王姐姐的建议和指导下完成的。不得不说，调试加密算法是非常复杂的事情，这种事情我也干过，但时间不长，而王姐姐是这方面的老手！即便对于Dave Watson而言，可能真的就是因为加密算法，HAMC算法非常复杂才迫使其不得不先出一个仅仅支持GCM(aes) 128bit的简化版本的吧...不过听王姐姐说，RFC5288所描述的要比CBC模式快很多，而安全性相当，并且不再需要独立计算HMAC，相信Dave也懂这个。所以说，Dave的所谓“简化版”KTLS并非因为这样实现简单。&&&&&&& 关于加密算法就到此为止吧，这个周末抽点时间研究一下GCM的原理。----------------我的修改主要是把AF_ALG socket的操作改成了AF_KTLS socket操作：.... // 等价的OpenSSL操作
/* Kernel TLS tests */
int tfmfd = socket(AF_KTLS, SOCK_STREAM, 0);
if (tfmfd == -1) {
perror(&socket error:&);
struct sockaddr_ktls sa = {
.sa_cipher = KTLS_CIPHER_AES_GCM_128, /* 指定cipher suit*/
.sa_socket = server, /* 指定附着的TCP socket */
.sa_version = KTLS_VERSION_1_2,
if (bind(tfmfd, (struct sockaddr *)&sa, sizeof(sa)) == -1) {
perror(&AF_ALG: bind failed&);
close(tfmfd);
EVP_CIPHER_CTX * writeCtx = ssl-&enc_write_
EVP_CIPHER_CTX * readCtx = ssl-&enc_read_
EVP_AES_GCM_CTX* gcmWrite = (EVP_AES_GCM_CTX*)(writeCtx-&cipher_data);
EVP_AES_GCM_CTX* gcmRead = (EVP_AES_GCM_CTX*)(readCtx-&cipher_data);
unsigned char* writeKey = (unsigned char*)(gcmWrite-&gcm.key);
unsigned char* readKey = (unsigned char*)(gcmRead-&gcm.key);
unsigned char* writeIV = gcmWrite-&
unsigned char* readIV = gcmRead-&
char keyiv[20] = {0};
memcpy(keyiv, writeKey, 16);
if (setsockopt(tfmfd, AF_KTLS, KTLS_SET_KEY_SEND, keyiv, 16)) {
perror(&AF_ALG: set write key failed\n&);
memcpy(keyiv, writeIV, 4);
if (setsockopt(tfmfd, AF_KTLS, KTLS_SET_SALT_SEND, keyiv, 4)) {
perror(&AF_ALG: set write iv failed\n&);
uint64_t writeS
unsigned char* writeSeqNum = ssl-&s3-&write_
memcpy(&writeSeq, writeSeqNum, sizeof(writeSeq));
if (setsockopt(tfmfd, AF_KTLS, KTLS_SET_IV_SEND, (unsigned char*)&writeSeq, 8)) {
perror(&AF_ALG: set write salt failed\n&);
memcpy(keyiv, readKey, 16);
if (setsockopt(tfmfd, AF_KTLS, KTLS_SET_KEY_RECV, keyiv, 16)) {
perror(&AF_ALG: set read key failed\n&);
memcpy(keyiv, readIV, 4);
if (setsockopt(tfmfd, AF_KTLS, KTLS_SET_SALT_RECV, keyiv, 4)) {
perror(&AF_ALG: set read iv failed\n&);
uint64_t readS
unsigned char* readSeqNum = ssl-&s3-&read_
memcpy(&readSeq, readSeqNum, sizeof(readSeq));
if (setsockopt(tfmfd, AF_KTLS, KTLS_SET_IV_RECV, (unsigned char*)&readSeq, 8)) {
perror(&AF_ALG: set read salt failed\n&);
....// 在tfmfd socket上的send/recv/sendfile，由tfmfd socket完成记录加密解密和协议的封装解封装，与其下的TCP/UDP socket交互。-----------------------------------在继续另一个基于AF_ALG的KTLS方案之前，我这里插几句评价。&&&&&&& 我个人觉得，KTLS并不仅仅是一个优化TLS的patch，而应该是一个名副其实的TLS，即传输层安全！在KTLS之前，基于OpenSSL等用户态库进行的封装都只能被成为“buffer安全”，并非真正的传输层安全，因为封装后的数据仅仅是一个socket的buffer。我个人比较关注整体架构，所以我才在这里咬文嚼字。&&&&&&& 可能是因为Facebook没有Google那么大的影响力吧，加之Dave Watson这个人比较低调，所以KTLS才没有引来一阵吹捧甚至盲目跟风，相反，质疑的声音却不断，某种意义上这倒是好事，可以让人冷静地思考这么做是否真的有必要，真的有必要把TLS协议放在内核中实现吗？&&&&&&& 诚然，Dave Watson本人也并不建议将整个TLS协议全部在内核层实现，而仅仅针对对称加密操作以及封装操作这种固定且稳定的操作。之所以将对称加密以及封装操作向下卸载，完全是因为这类操作是“固定的一套序列化的操作”。这就跟TCP将计算校验和的操作以及分段操作卸载到网卡而不把TCP三次握手以及拥塞控制卸载到网卡的道理一样，人们在希望通过向下卸载的手段达到优化的目的之前，必须权衡实现的复杂性以及效率，并在两者中间寻找一个平衡点。另外要考虑的就是，一旦卸载的部分在标准上发生了改变，升级操作的代价有多大。&&&&&&& TLS协议和TCP协议的发展非常类似，如果愿意，你也可以把TCP协议分为握手协议和记录协议，和TCP计算校验码以及分段一样，TLS的记录协议部分的操作非常固定，AES/DES这种对称加密算法非常稳定且固定，很久都不会发生改变，与之不同的是，TLS握手以及证书的处理却既复杂又多变。正如作者所希望的，KTLS希望乘着将对称操作从用户态程序库的剥离这种一鼓作气之风，最终推动网卡厂商来实现这个硬件卸载操作，即将对称加密和TLS记录协议封装的操作完全卸载到网卡！&&&&&&& 不管怎样，KTLS可能还是不够火候，在文章《》的最后，有这么一段话：Overall, it looks like it will take some more convincing arguments before putting TLS in the kernel will be seriously considered. For some specialized situations, it might make sense to do so, but even the limited version Watson posted adds more than 1200 lines of code to the kernel—for dubious gains. Over time, more and more crypto has been added to the kernel, though, so maybe TLS will eventually find its way in too. 我和温州皮鞋厂老板的对话就不贴了，温州老板特别想搞一个这样的项目制造点影响力，我表示我会全力支持。----------------我个人非常赞同Dave Watson的观点。但是，你可曾想到，假设这个KTLS被应用，那么将会有什么必须改变？！需要改变的是Apache，Nginx这种主流服务器的HTTPS处理逻辑，将所有调用SSL_read/write的地方改成基于KTLS的recv/send/sendfile，无疑，改变的代价非常巨大！&&&&&&& 我称赞KTLS的朴素原因可能源自于我对OpenSSL的偏见，这属于个人情感的范畴，就不做煽动之辞了。&&&&&&& 随着安全越来越重要，加密通信再也不是一个额外的组件了，它会内化成网络协议的一部分，这可以从HTTPS的逐渐风靡看出来，“buffer安全”还是“传输层安全”，哪个是你的追求呢？请继续管中窥豹吧！-----------------------------------现在该谈一下另一种方案了。&&&&&&& 要实现KTLS，除了像上述那般直接实现一个AF_KTLS socket，还有一种方案，就是直接基于AF_ALG socket来实现，让AF_ALG socket可以做sendfile的fd_in参数！因此事实上，这也是Dave Watson的那个algif_tls方案，关于该方案的patch以及讨论的patchwork地址是：&&&&&&& 要想理解这种做法的合理性，我需要稍微花点篇幅来介绍一个Linux内核的AF_ALG机制。&&&&&&& AF_ALG是一种socket的类型，与AF_INET并列，该socket类型旨在导出一族用户接口，应用程序可以通过调用socket接口的方式来进行加密，解密操作。&&&&&&& 关于AF_ALG的最初的patch介绍，请先看一下Lwn文章《》。如果你已经研究了代码，那么不难理出下图所示的关系：首先，我们可以看出，最初通过socket建立的一个AF_ALG socket只是一个设置crypt机制的socket，最终需要调用accept来获取一个操作socket，这个过程非常类似TCP以及Linux的INIT进程！其次，我们注意到af_alg_type这个结构体非常重要，它存在的本意是让你可以实现不同的Crypto API，比如调用不同的加密算法，但它也使得自定义任何操作成了可能，你可以让一个AF_ALG socket在调用send的时候仅仅完成加密解密，然后在recv的时候将结果导出，也可以将一个AF_ALG OP socket附着在一个TCP socket或者UDP socket上，在调用send的时候，首先完成加密，然后将结果通过其附着的TCP socket或者UDP socket发出到网络，随便怎么做，取决于af_alg_type这个里面的回调你怎么实现。&&&&&&& AF_ALG Frame socket本身只是一个抽象的框架，具体的工作要通过将其与一个af_alg_type相关联，由其生成的一个OP socket来完成。这个原理为Dave实现algif_tls这个patch提供了依据，事实上，他就是实现了一个algif_tls结构体：static struct proto_ops algif_tls_ops = {
// sendmsg/page 1.加密消息；2.通过TLS记录协议封装消息；3.发送到底层附着的TCP/UDP socket
tls_sendmsg,
tls_sendpage,
// recvmsg 1.获取底层附着的TCP/UDP socket的数据；2.解封装数据；3.解密数据后拷贝到用户态缓冲区
tls_recvmsg,
sock_no_poll,
static const struct af_alg_type algif_type_tls = {
// bing 创建底层crypto_aead基础设施
tls_release,
// setkey 在底层crypto_aead设施上设置密钥
tls_setkey,
.setauthsize
tls_setauthsize,
// accept 获取一个OP socket用于实际的读写操作，并将以下的ops字段作为其操作回调集合
tls_accept_parent,
// ops 实际的OP socket的回调集合
&algif_tls_ops,
// name 在Frame socket进行bind的时候，可以通过这个name找到该algif_tls_ops，用于索引
THIS_MODULE
};我们来通过Dave的这个例子看一下到底如何操作：/* Kernel TLS tests */
// 首先创建Frame socket
int tfmfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
// 创建一个索引结构体，用于查找已经注册进内核的af_alg_type
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = &tls&, /* this selects the hash logic in the kernel */
.salg_name = &rfc5288(gcm(aes))& /* this is the cipher name */
// 根据上述的sa建立Frame socket与af_alg_type的关联
if (bind(tfmfd, (struct sockaddr *)&sa, sizeof(sa)) == -1)
// 获取一个操作实际IO的OP socket
int opfd = accept(tfmfd, NULL, 0);
...// 以下OP socket的行为完全取决于af_alg_type中的ops字段指示的proto_ops回调集了。以上就是AF_ALG socket的框架以及Dave Watson在此框架上实现的不同于AF_KTLS的另一种KTLS方案。但是这并不是我要说的全部，既然AF_ALG的框架这么灵活，那为什么还要单独搞一个新的socket类型AF_KTLS呢？这可能是一个形而上的问题，我把中的内容摘录如下，来自af_alg的作者Herbert Xu：On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote:& Userspace crypto interface for TLS.& Currently supports gcm(aes) 128bit only,& however the interface is the same as the rest of the SOCK_ALG interface, so it& should be possible to add more without any user interface changes.SOCK_ALG exists to export crypto algorithms to user-space.& So ifwe decided to support TLS as an algorithm then I guess this makessense.However, I must say that it wouldn't have been my first pick.& I'dimagine a TLS socket to look more like a TCP socket, or perhaps aKCM socket as proposed by Tom.于是，AF_KTLS难道就是一个更加合理的选择吗？&&&&&&& 现在继续AF_KTLS和AF_ALG+自定义af_alg_type孰优孰劣的形而上讨论。个人认为还是AF_ALG+自定义af_alg_type更加灵活，你只需要自己实现一个af_alg_type并且注册进内核，就可以实现任何形式的封装，甚至实现一个完整的HTTP协议的处理过程。完全不像AF_KTLS那样自己实现一个完整的socket类型，那样会让你陷入类似ioctl分发类似的泥潭。诚然，sendfile将2.4内核的Kernel Web Server踢出了内核，但是AF_ALG+自定义af_alg_type则是更加通用的机制，它可以实现任何应用层协议！-----------------------------------还记得我在2014年到2015年间将OpenVPN的数据通道协议移植到了内核态，github地址在：&&&&&&& 这个工作与Dave Watson的工作非常类似，仔细研究了Dave的KTLS之后，我本来想花这个周末的时间重新再重构一下这个KOpenVPN了，但是显然感到无力，所以我退而求其次，我只是想基于AF_ALG+自定义af_alg_type来实现一个简单的HTTP协议，仅用来传输文件，大体逻辑非常简单，即通过sendfile将一个文件发送给一个AF_ALG OP socket，然后实现一个af_alg_type完成HTTP头的添加后再继续发给底层的INET socket。如果换一种方式，我也可以单独写一个AF_MYHTTP模块来用一个新型的socket更加直接地实现上述需求。------------------------------------在完成了这篇文章后，我的下一个挑战就是，日要在小小幼儿园的小区开阔场地开唱《新长征路上的摇滚》(这源自于几周前小小秋游时在路上我被疯子逼着唱了一首《假行僧》，然后幼儿园老师就非要让我在新年联欢会上再来一首摇滚...)...有点紧张，决定喝瓶酒再上！好在疯子可以陪我上去唱《One night in BeiJing》....有人陪我丢人，总比一个人丢人强吧...总之，加油吧！为了孩子，啥都可以付出，唱个歌丢一回人算个毛线啊！
本文已收录于以下专栏：
相关文章推荐
简介SSL(Secure Socket Layer)是netscape公司提出的主要用于web的安全通信标准,分为2.0版和3.0版.TLS(Transport Layer Security)是IET...
如今几乎每个人都听说过Linux中所谓的"零拷贝"特性，然而我经常碰到没有充分理解这个问题的人们。因此，我决定写一些文章略微深入的讲述这个问题，希望能将这个有用的特性解释清楚。在本文中，将从用户空间应...
本文为线程本地存储TLS系列之分类和原理。
一、TLS简述和分类
我们知道在一个进程中，所有线程是共享同一个地址空间的。所以，如果一个变量是全局的或者是静态的，那么所有线程访问的是同一份，...
关于OpenVPN数据通道的一次优化正在进行中，当我参考了”巨型帧“的概念和思想后，我仔细思考了TCP/IP协议栈的设计和实现，于是我得出了一个可能是错误但是起码在我的场景中很实用的结论：上层协议尽管...
深入OpenVPN的配置
在实际使用中，可能还会遇到很多网络上的问题，今天就再举几个例子说明一下。
针对不同的客户端...
首先，我的大名叫做Transport Layer Security Protocol（传输层安全协议），是SSL的升级版。实际上我的左手和右手都是能用的，左手叫Record Layer（记录层），右手...
Linux的TLS（Thread
Local Storage）实现由内核和用户两部分模块配合完成的。
内核对TLS需要做的事情是能够让用户态程序（通常是 nptl——一个pthread的实现...
tcp_syn_retries ：INTEGER
对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255，默认值是5，对应于180秒左右时间。(对于大负载而物...
cp_syncookies是一个开关，是否打开SYN Cookie功能，该功能可以防止部分SYN攻击。tcp_synack_retries和tcp_syn_retries定义SYN的重试次数。
关于SSL/TLS/JSSE的介绍：
1）SSL/TLS协议运行机制
2）图解SSL/TLS协议
3）使用wireshark观察SSL/TLS握手过程
4）SSL/TLS的Java实现--JSSE
他的最新文章
讲师：李江龙
讲师：司徒正美
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
SSL/TLS真的被BEAST攻击攻破了吗？
关键字：BEAST SSL/TLS 新闻
　　更新：2015.1 。 v3应该被关闭。RC4现在不再，因此不应再使用，即使是为了对抗BEAST攻击。LuxSci建议使用TLS v1.1+和 NIST推荐算法 ，BEAST攻击现在也不再是一个很大的威胁了(即使在使用TLS v1.0的情况下)。
　　更新：2012.4。openssl v1.0.1已经发布，其支持TLS v1.1和v1.2，这会帮助缓解这种攻击。
　　根据一种 最近发布的攻击机制 ( 称为BEAST )， SSL v3和TLS v1面临一种严重的威胁。这听起来动摇了安全的根基，带来了一定程度的恐慌。当人们看到这个问题时，会浮现出如下几个问题：
　　实际的影响是什么？ 它有多严重？ 我该如何保护自己？ BEAST攻击是如何工作的？
　　在研究了这个问题后，我们对所发现的问题进行了概要，撰写了本文来回答这几个问题。
　　BEAST的实际影响是什么？
　　该问题可能影响浏览安全站点的人们，在某种条件下会导致窃听者能获取到你站点账户的访问权。它 不会 影响：
　　使用 SSL/TLS 的其他，例如emal使用的 IMAP, POP或SMTP 。 使用SSL安全的站点连接来发送(例如：使用 web forms 发送数据)(？不大懂)
　　它会影响：
　　你需要在安全站点上登录使用的帐号，例如, LuxSci, Gmail, Bank of America,等。
　　我浏览网站的什么时候会被攻击？
　　如果你使用的中，有恶意人员可以查看网络中所有的正常流量，并且可以截获并修改流量，那么他可能会危害你的安全网站浏览。
　　注意这并 不包括 和你使用同一个或的恶意人员，他们只能窃听到你的非安全连接，SSL 对抗他们还是很有效 的。但会包括如下场景：
　　本地网络管理员是个坏家伙 攻击者攻破了你的本地网络，获取到了的控制权 你在一个对出入网络流量进行监控的国家(呵呵)
　　没有在那些国家并且使用可信网络的人们大可不必太过担心。这里的“可信”指的是：
　　你的本地ISP(例如：Comcast，，Verizon等，类似国内的、电信)基本是可信的。我们对他们是深度信任的--如果他们想，他们可以有更为简单的方法来干坏事(例如通过将或植入你的系统)。 你所在学校或公司的网络管理团队基本是可信的(这些家伙可以知道你在网络中做过的任何事情)。和ISP一样，他们如果想干坏事，有比TLS攻击更为简单且效果更好的方式。 政.府--你相信他们不会强迫ISP窃听你吗？即使他们会，大部分人也不用太过担心。
　　这种攻击发生在恶意人员想要窃听你的或在不知道先验知识的情况下访问你的帐号，他们可能(a)已经知道了你访问web站点的频率，或者(b)已经访问了足够多人的web流量，并且他们只想攻击非常流行的网站账户，例如Gmail，paypal或某些银行。
　　如果你对此比较担心，这是否是一个潜在的威胁取决于你所处的位置和你做了什么。
　　什么情况下我可能会被攻击成功？
　　简答来说，如果针对你发起了攻击，如果你做了如下的事情，可能会被攻击成功：
　　你访问了任意非安全站点(http的而非https的)，并且你的启用了JavaScript。 你使用相同的浏览器访问超过10分钟。 然后你访问安全站点，而攻击者正想冒充你访问该站点。
　　注意，攻击者必须 提前约10分钟 猜测或者知道你将会访问那个安全站点。10分钟的间隔会随着攻击所使用的计算能力的增加而减少。
　　举个例子，我们假设攻击者想要窃听每个人的gmail帐号访问以便获取用户名、口令和其他敏感。
　　你访问一个不安全的站点，例如http://.com 攻击者收集和处理访问所需要的数据 你继续上网一段时间 你访问以检查你的email 攻击者可以使用已经收集的信息来访问你的Gmail帐号，就像他已经以你的身份登录一样。
　　我如何保护自己？
　　如果你对这种攻击比较在意，你可以通过如下方式来保护自己：
　　关闭你的浏览器(所有打开的窗口) 打开你的浏览器，直接访问安全的站点，而不要在之前访问不安全的站点
　　这种方式之所以凑效是因为这种攻击需要相同的浏览器使用一段时间。关闭并重新打开浏览器可以使攻击者的准备工作失效。直接访问安全站点避免了攻击者的准备工作。
　　你可以通过很简单的方法达到这个目标：
　　将你的主页设为一个安全页面，例如 。然后你可以使用浏览器收藏夹来访问你想要去的安全站点。 将你经常访问的安全站点书签放到桌面上，当你点击它是可以直接打开你想去的安全站点。 在你的浏览器上禁用JavaScript，或者旨在可信的安全站点中启用。 使用。如果你将电脑连接到可信的网络(例如工作环境)，这将会通过VPN发送所有安全的和不安全的web连接，从而避开了网络内的恶意人员查看和干扰你浏览的任何内容。
　　另外，如果攻击者不知道你的浏览习惯，并且你访问的站点不是非常流行，他们很难危害到你。例如：诸如，facebook，等网站的用户量巨大，因此也容易成为攻击目标，比较小的网站如则一般不会。然而，如果攻击者知道你访问习惯，就会满盘皆输了。
　　BEAST攻击是如何工作的？
　　当你访问不安全的站点，攻击者修改了返回的页面或返回的JavaScript，在其中添加了恶意的JavaScript。 恶意的JavaScript在你的浏览器中自动执行(如果你启用了JavaScript的话)。 JavaScript打开一个安全的连接，例如到 攻击者将你的浏览器与之间的流量与已知的通过JavaScript发送的流量进行对比，进行几分钟的计算，攻击者可以可以得到你安全会话的“初始向量”。 这个信息允许攻击者访问在同一个浏览器会话中发往相同站点的后续安全认证cookies。 这些cookies可以被攻击者“重放”，这样他们就拥有了你账户的全部访问权，就像以你的身份登录了一样。他们可以查看任何敏感信息，并且可以冒充你执行操作。
　　需要注意如下几点：
　　攻击者需要在你的浏览器执行JavaScript。 需要有一个不安全的web连接，以便攻击者能修改返回的内容。 攻击者需要猜测你即将访问的安全站点。 攻击者需要花费时间来收集和。 你必须随之连接并登录相同的站点，在相同的浏览器会话中(没有关闭并重新打开浏览器或使用不同的浏览器)。 攻击者必须在你的会话仍然活跃的时候才能执行恶意行为(如果你主动退出，也会把攻击者一同退出，希望攻击者没有更改你的口令)。
　　另外：
　　该攻击影响SSL v3和TLS v1.0 该攻击不影响TLS v1.1和TLS v1.2
　　那么，我可以只使用 “TLS v1.1″ 或“TLS v1.2″吗?
　　答案是“某些情况下是的”。
　　只有IE和支持TLS v1.1或更高的版本。所有其他的浏览器(chrome、firefox、safari和大多数)都 不支持这些最新的安全协议 (译者注：该文章写于2011年，现在各浏览器的最新版本基本都支持了)。另外，即使IE支持，默认也是禁用的 。 另外启用它们也可能会影响一些常规的安全站点，例如如果你启用后一些站点不再工作了(译者注：这种情况发生在你只启用了TLS1.2，但服务器最高支持到TLS1.0的情况下，如果客户端同时也启用了TLS1.0，则不会有问题)。 大部分还不支持TLS v1.1或TLS v1.2，所以即使你的浏览器支持，你要访问的安全站点可能也不支持，例如 , ， 等都不支持(译者注：仍旧是老黄历)。根据 Opera的统计 ，只有0.25%的web服务器支持TLS v1.1或更新的版本。
　　为什么大多数服务器不支持TLS v1.1+？
　　标准的产品级SSL软件库，例如openssl，尚不支持TLS v1.1，因此大多数web站点无法启用。虽然正在开发中的openssl支持，但由于其性能、可靠性和bug等方面的原因，还无法包括在标准的分发库中。(译者注：仍旧是老黄历) 至今还没有对TLS v1.1和v1.2的强烈需求。
　　LuxSci正在与各个厂商(例如RedHat)联系，看是否可以将TLS v1.1的支持加入到现有的分发库中，以便使用者可以便利的升级。
　　其他可能的选择，包括使用其他的SSL系统或使用openssl尚未良好验证的最新版，都不是一个好的办法，因为这些可能需要多次的升级、大量的测试，升级时可能甚至可能需要停机。使用替代方式也意味着任何openssl后续安全升级的新特性都必须进行手工管理或依赖于尚待实现的升级机制，这就是替代没有大规模使用的原因，TLS v1.1-的版本具备标准的自动升级机制。
　　你可以检查通过使用 SSLLabs web 来检查任何web站点的SSL功能以及其是否支持TLS v1.1或v1.2。
　　浏览器的升级情况如何？
　　浏览器厂商正在调查这个问题以确定会给用户带来多大的影响。我们希望他们发布一些浏览器升级包以减缓该攻击的影响程度，同时不需要服务器升级至TLS v1.1.虽然服务器升级长期来看是需要的，但至少不用这么着急。
　　给该问题的评级相当低;Firefox说即将开发一个修复程序;其他的TLS专家目前不太关注该问题。
　　其他一些信息
　　人们应该意识到安全是不断变化的。我们认为出了升级和实现软件修补外，还要考虑如下几点：
　　当任何可能的时候都使用SSL/TLS。不安全的站点对我们的浏览器和计算机是一个风险，因为我们无法控制任何恶意的第三方对我们浏览会话的注入，SSL和TLS客户保护我们远离这种威胁。 当访问安全的web站点时，最好新开一个浏览会话或已经浏览过安全的https站点。 将你的主页设为安全的站点，并且将其他的安全站点加入到收藏夹中。 针对普通的不安全浏览和安全浏览使用不同的浏览器。 保持你的软件、浏览器、操作系统、防病毒软件和其他组件更新到最新。
　　如果浏览器厂商发布了此问题的修补程序，威胁等级将显著降低。当前威胁程度也比较低，但是因为还很少有人会利用这个漏洞。
　　不过，以后相似的挟持不安全连接的攻击在以后很可能会呈现上升态势。将安全和不安全站点分别使用不同的浏览器是一个好习惯。
　　主动的安全习惯是一件好事情。
相关文章：
[ 责任编辑：小石潭记 ]
去年，手机江湖里的竞争格局还是…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte