精华内容
下载资源
问答
  • 0bfs 混淆

    2020-10-31 17:53:31
    obfs 混淆最大的作用是对 SS 流量进行伪装, 在不添加obfs的情况下, 运营商服务器通过的流量为未知的加密流量, 据说 GFW 已经有...混淆方式理论上tls是最佳,但目前以联通上网记录最直观的结果来看,使用tls混淆会使混

    obfs 混淆最大的作用是对 SS 流量进行伪装, 在不添加obfs的情况下, 运营商服务器通过的流量为未知的加密流量, 据说 GFW 已经有一定的包检测的能力, 仅仅加密流量具有一定的风险, 添加 obfs http 模式之后, 通过运营商的流量会被识别为设定好的网址的流量, 假设你设定的是 bing, 那么你的 SS 流量会被判别为你当前正在访问 bing, 减少了被封杀的可能性,tls模式安全性高于http模式

    混淆方式理论上tls是最佳,但目前以联通上网记录最直观的结果来看,使用tls混淆会使混淆域名“无效”直接显示代理服务器IP,而http可以正常显示混淆域名,至少看上去达到了伪装的效果,故,目前而言,推荐使用http混淆。

    之前流量不是无限的时代, 因为只有运营商的 APP 可以无限使用流量, 比如什么天翼视讯, 利用 obfs 混淆, 可以将你的手机流量伪装为天翼视讯的流量, 从而达到无限使用使用流量, 这种操作太骚, 实测可以成功, 不过还是低调的好.

     

     

    本地配置

    服务器端已将安装了 obfs, 本地端直接下载obfs-local插件, 解压后将插件 obfs-local 与Shdow*.exe 同一路径下即可.

     

    obfs可以直接在SS的服务器编辑页面修改参数

     

    插件选项为 obfs=http;obfs-host=www.bing.com, 实际上可以将 www.bing.com 更换为任意的一个网址, 只要不是被GFW封杀的就可以, 推荐像腾讯视频, 优酷, bing这种流量较大的网站, 如果填写是Google或者YouTube, 活着不好么......

    展开全文
  • SSL vs TLS vs STARTTLS

    千次阅读 2018-08-14 07:11:32
    SSL, TLS和STARTTLS都是在计算机安全里面, 都很容易让人混淆的词. SSL和TLS都提供了加密2台计算机(如服务器和客户端)之间通信的办法. TLS是SSL的继任者, 所以除非提到具体协议的版本,TLS和SSL这2个词是可以混用的, ...

    翻译者:易建科技基础架构中心研发经理张冬卯

    SSL vs TLS vs STARTTLS

    SSL, TLS和STARTTLS都是在计算机安全里面, 都很容易让人混淆的词.

    SSL和TLS都提供了加密2台计算机(如服务器和客户端)之间通信的办法. TLS是SSL的继任者, 所以除非提到具体协议的版本,TLS和SSL这2个词是可以混用的, 在大多数情况下的意思相近.

    STARTTLS是一种把已经存在的一条不安全的链接, 用SSL/TLS的加密方法, 把这条不安全的连接升级成安全的连接. 注意, 尽管STARTTLS里面只有"TLS", 但是你既可以用TLS也可以用SSL.

    SSL/TLS的版本号

    由于历史原因, SSL和TLS之间的版本号顺序并不一致, 当TLS代替SSL作为下一代的加密标准时, TLS采用了新的版本号, 并且

    新的版本号下面还有小版本号. 所以按照时间顺序, SSL/TLS的软件版本序号从最老到最新的顺序应该是: SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2, TLS v1.3

    [译注: 比如我用chrome连接知乎的443端口, 看到的是TLS v1.2加密]

    当客户端连接到一个SSL/TLS加密的端口, 或者用STARTTLS升级当前连接时, 通信双方根据双方软件的配置, 做自动协商, 选择某一种SSL/TLS做加密通信.

    大量的软件都已经默认支持SSL/TLS[译注: 如浏览器, 邮件客户端, HTTP服务器]. SSL v2早已再多年前由于存在安全漏洞弃之不用. SSL v3也由于有安全漏洞不再使用. 几乎所有软件都支持TLS v1.0. 在2016年10月, TLS v1.1 和 TLS v.2 也已经被广泛的支持.

    尽管IE对TLS支持有一些例外.

    总有软件搞混TLS和STARTTLS

    一个让事情更加复杂的因素是一些邮件客户端也会搞混这2个名词.当他们应该用STARTTLS这个词时, 但他们却错误地用成了TLS.

    比如,老版本的Thunderbird里面的选项"TLS"表达的意思是"强制使用STARTTLS升级当前连接, 如果协商失败, 返回连接失败". 另外一个选项

    "TLS, if availiable"表达的是"如果服务器支持STARTTLS, 那么就用STARTTLS通信, 如果服务器不支持STARTTLS,那就不安全连接"

    SSL/TLS 和STARTTLS的端口

    为了增强已有的邮件协议(如IMAP, POP)的安全性, 但是并不破坏原有协议, 协议工程师的做法再是原有协议不变的基础上, 在邮件协议下方增加一个SSL/TLS的传输加密层. 但是为了区分这个协议是明文的邮件协议还是加密的邮件协议, 每种邮件协议都增加了一个额外的端口来传输加密的数据. 所以:

    IMAP协议默认端口 143, SSL/TLS 加密的IMAP的默认端口是993

    POP 协议默认端口110, SSL/TLS 加密的POP的默认端口是995

    SMTP协议默认端口25, SSL/TLS加密的SMTP的默认端口是465

    从某种角度看, 每种邮件协议占据2个端口是一种浪费. 所以, 出现了一个解决办法, 你可以只需要使用一个端口.通过普通端口生成的连接起初是不加密的, 但是双方可以通过STARTTLS协议把这个非加密连接升级成加密连接.

    上面每种邮件协议都加入了新的协商机制, 邮件服务器告诉客户端当前的明文协议支持升级成加密的连接.在当前连接升级到加密连接之前, 不要做登录操作(传输用户名和密码). 在实现不完整的邮件客户端中, 会出现下面2种错误的处理方法:

    一些邮件客户端忽略了服务器表达的"直到升级到加密连接前, 不要发登录密码", 还是尝试登录, 用明文发送用户名和密码. 即使服务器拒绝了这个明文登录, 但是用户名/密码还是已经泄露到互联网中

    另一些邮件客户端看到了"直到升级到加密连接前, 不要发登录密码"这个声明. 但它不自动升级当前连接, 而是直接向用户报告登录失败

    上面这2个问题引发了现存的邮件客户端广泛的兼容性问题, 所有大多数系统管理员仍然使用双端口的解决方案, 一个端口传输明文协议, 另一个端口传输加密数据.

    由于2个端口很容易让客户混淆, 很多邮件服务商采用了一刀切的办法, POP和IMAP协议只保留加密端口, 现在这个配置变成了目前的事实标准. 很多网站禁用了明文传输端口(IMAP的143和POP的110), 强制用户使用加密连接. 由于不再存在明文端口, 这些邮件网站也不再支持STARTTLS协议.

    SMTP的STARTTLS是一个例外

    [译注: 上文只说很多网站的POP和IMAP协议只支持加密端口, 但是SMTP仍然支持非加密端口]

    一个例外是SMTP协议. 很多网站还支持非加密端口的SMTP是另一个原因. 大部分邮件客户端用SMTP协议在端口25提交邮件. 但是SMTP协议最初设计在MTA之前传输邮件.所以新的端口587被rfc定义用来提交邮件.

    尽管新端口587没有强制用户使用STARTTLS, 但是随着邮件客户端和邮件服务器之前的安全通信的重要性越来越高, 端口587也变得越来越流行. 所以, smtp的SSL/TLS端口465也被标准回收, 推动用户迁移到新端口587上用STARTTLS协议做加密传输.

    结果是在大多数情况下, 邮件系统允许普通用户从端口587通过STARTTLS协议提交邮件(用户安全的提交用户名密码). 通过把邮件提交任务从端口25迁移走, 运行商现在可以封锁所有普通用户25端口, 通常端口25也是垃圾邮件的来源.

    不幸的是, 修改SMTP的默认端口的缺点是, 存在大量的邮件客户端, 他们只支持在端口465上的SSL/TLS, 不支持在端口587上的STARTTLS.但是邮件客户端的更新很慢, 所有邮件运营商为了兼容性考虑, 都不会移除端口465.

    目前, SMTP的情况是这样, 一些人使用STARTTLS在端口587上登录服务器, 另一些人在端口465用SSL/TLS登录邮件服务器.

    [译注: 但一些国内的情况更糟, 一些邮件运营商仍然没有用标准的587端口, 而仍然沿用25端口, 这时候需要用STARTTLS在25端口上登录服务器]

    ========翻译完========

    以上就是我们写登录SMTP服务器代码时注意事项, 一定要知道SMTP的打开的端口是SSL/TLS端口还是明文的需要升级的STARTTLS端口,

    然后还要知道Auth的方式, 比如PLAIN AUTH还是LOGIN AUTH等等, 要把这些排列组合才可以正确的发邮件.

    用golang表示的代码例子:

    用STARTTLS连接SMTP服务器

    https://gist.github.com/jim3ma/b5c9edeac77ac92157f8f8affa290f45gist.github.com

    直接用SSL/TLS连接SMTP服务器

    https://gist.github.com/chrisgillis/10888032gist.github.com

    由于golang标准库smtp不支持Login Auth, 需要自己加入新的Auth才可以登录smtp服务器:

    https://gist.github.com/andelf/5118732gist.github.com

    此外还有如果用TLS连接SMTP服务器, 有时候会发现报错:

    panic: x509: certificate is valid for XXX

    这是说明邮件的证书没有被ROOT CA认证, 当然和你无关, 解决办法是再tlsconfig里面加一个选项InsecureSkipVerify:

    tlsconfig := &tls.Config{ ServerName:host, InsecureSkipVerify:true }

    展开全文
  • TLS原理

    千次阅读 2007-06-20 16:16:00
    cited from http://ciw.chinaitlab.com/tech/7319.html一 前言 首先要澄清一下名字的混淆: 1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。 2 IETF...

    cited from http://ciw.chinaitlab.com/tech/7319.html

    一 前言
      
      首先要澄清一下名字的混淆:
      1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。
      2 IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为TLS(Transport Layer Security),从技术上讲,TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别,本文中这两个名字等价。
      3 在WAP的环境下,由于手机及手持设备的处理和存储能力有限,wap论坛(www.wapforum.org)在TLS的基础上做了...S协议(Wireless Transport Layer Security),以适应无线的特殊环境。
      
      我们从各式各样的文章中得知,SSL可以用于保密的传输,这样我们与web server之间传输的消息便是“安全的”。
      而这种“安全”究竟是怎么实现的,最终有能实现多大程度的保密?本文希望能用通俗的语言阐明其实现原理。
      
      
      二 整体结构概览
      
      SSL是一个介于HTTP协议与TCP之间的一个可选层,其位置大致如下:
      
      ---------
      | HTTP |
      ---------
      | SSL |
      ---------
      | TCP |
      ---------
      | IP |
      ---------
      
      如果利用SSL协议来访问网页,其步骤如下:
      用户:在浏览器的地址栏里输入https://www.sslserver.com
      HTTP层:将用户需求翻译成HTTP请求,如
      GET /index.htm HTTP/1.1
      Host http://www.sslserver.com
      
      SSL层: 借助下层协议的的信道安全的协商出一份加密密钥,并用此密钥来加密HTTP请求。
      TCP层:与web server的443端口建立连接,传递SSL处理后的数据。
      
      接收端与此过程相反。
      
      SSL在TCP之上建立了一个加密通道,通过这一层的数据经过了加密,因此达到保密的效果。
      
      SSL协议分为两部分:Handshake Protocol和Record Protocol,。其中Handshake Protocol用来协商密钥,协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
      
      
      三 需要的加密方面的基础知识
      了解SSL原理需要一点点加密的概念,这里把需要的概念做一下简单阐述:
      
      加密一般分为三类,对称加密,非对称加密及单向散列函数。
      
      对称加密:又分分组密码和序列密码。
      分组密码是将明文按一定的位长分组,明文组经过加密运算得到密文组,密文组经过解密运算
      (加密运算的逆运算),还原成明文组。
      序列密码是指利用少量的密钥(制乱元素)通过某种复杂的运算(密码算法)产生大量的伪随机位流,用于对明文位流的加密。
      解密是指用同样的密钥和密码算法及与加密相同的伪随机位流,用以还原明文位流。
      
      CBC(Cipher Block Chaining)模式这个词在分组密码中经常会用到,它是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算。当加密算法用于此模式的时候除密钥外,还需协商一个初始化向量(IV),这个IV没有实际意义,只是在第一次计算的时候需要用到而已。采用这种模式的话安全性会有所提高。
      
      分组密码的典型例子为DES,RC5,IDEA。
      序列密码的典型例子为RC4。
      
      公钥加密:
      简单的说就是加密密钥与解密密钥不同,分私钥和公钥。这种方法大多用于密钥交换,RSA便是一个我们熟知的例子。
      还有一个常用的称作DH,它只能用于密钥交换,不能用来加密。
      
      单向散列函数:
      由于信道本身的干扰和人为的破坏,接受到的信息可能与原来发出的信息不同,一个通用的办法就是加入校验码。
      单向散列函数便可用于此用途,一个典型的例子是我们熟知的MD5,它产生128位的摘要,在现实中用的更多的是安全散列算法(SHA),SHA的早期版本存在问题,目前用的实际是SHA-1,它可以产生160位的摘要,因此比128位散列更能有效抵抗穷举攻击。
      
      由于单向散列的算法都是公开的,所以其它人可以先改动原文,再生成另外一份摘要。解决这个问题的办法可以通过HMAC(RFC 2104),它包含了一个密钥,只有拥有相同密钥的人才能鉴别这个散列。
      
      
      四 密钥协商过程
      
      由于对称加密的速度比较慢,所以它一般用于密钥交换,双方通过公钥算法协商出一份密钥,然后通过对称加密来通信,当然,为了保证数据的完整性,在加密前要先经过HMAC的处理。
      
      
      SSL缺省只进行server端的认证,客户端的认证是可选的。以下是其流程图(摘自TLS协议)。
      
      
      Client Server
      
      Clienth*llo -------->
      Serverh*llo
      Certificate*
      ServerKeyExchange*
      CertificateRequest*
      <-------- Serverh*lloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished -------->
      [ChangeCipherSpec]
      <-------- Finished
      Application Data <-------> Application Data
      
      简单的说便是:SSL客户端(也是TCP的客户端)在TCP链接建立之后,发出一个Clienth*llo来发起握手,这个消息里面包含了自己可实现的算法列表和其它一些需要的消息,SSL的服务器端会回应一个Serverh*llo,这里面确定了这次通信所需要的算法,然后发过去自己的证书(里面包含了身份和自己的公钥)。Client在收到这个消息后会生成一个秘密消息,用SSL服务器的公钥加密后传过去,SSL服务器端用自己的私钥解密后,会话密钥协商成功,双方可以用同一份会话密钥来通信了。
      
      
      五 密钥协商的形象化比喻
      
      如果上面的说明不够清晰,这里我们用个形象的比喻,我们假设A与B通信,A是SSL客户端,B是SSL服务器端,加密后的消息放在方括号[]里,以突出明文消息的区别。双方的处理动作的说明用圆括号()括起。
      
      A:我想和你安全的通话,我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH,摘要算法有MD5和SHA。
      
      B:我们用DES-RSA-SHA这对组合好了。
      这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份(把证书发给A)。
      目前没有别的可说的了。
      
      A:(查看证书上B的名字是否无误,并通过手头早已有的CA的证书验证了B的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了B的公钥的真实性)
      (产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密,封装成称作ClientKeyExchange的消息。由于用了B的公钥,保证了第三方无法窃听)
      我生成了一份秘密消息,并用你的公钥加密了,给你(把ClientKeyExchange发给B)
      注意,下面我就要用加密的办法给你发消息了!
      (将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥)
      [我说完了]
      
      B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了)
      注意,我也要开始用加密的办法给你发消息了!
      [我说完了]
      
      A: [我的秘密是...]
      
      B: [其它人不会听到的...]
      
      
      六 加密的计算
      上一步讲了密钥的协商,但是还没有阐明是如何利用加密密钥,加密初始化向量和hmac的密钥来加密消息的。
      其实其过程不过如此:
      1 借助hmac的密钥,对明文的消息做安全的摘要处理,然后和明文放到一起。
      2 借助加密密钥,加密初始化向量加密上面的消息。
      
      
      七 安全性
      SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论,
      目前也有一些成熟的工具如dsniff(http://www.monkey.org/~dugsong/dsniff/)可以
      通过man in the middle攻击来截获https的消息。
      
      从上面的原理可知,SSL的结构是严谨的,问题一般出现在实际不严谨的应用中。常见的攻击就是
      middle in the middle攻击,它是指在A和B通信的同时,有第三方C处于信道的中间,可以完全
      听到A与B通信的消息,并可拦截,替换和添加这些消息。
      
      1 SSL可以允许多种密钥交换算法,而有些算法,如DH,没有证书的概念,这样A便无法验证B的公钥
      和身份的真实性,从而C可以轻易的冒充,用自己的密钥与双方通信,从而窃听到别人谈话的内容。
      而为了防止middle in the middle攻击,应该采用有证书的密钥交换算法。
      2 有了证书以后,如果C用自己的证书替换掉原有的证书之后,A的浏览器会弹出一个警告框进行警告,但又有多少人会注意这个警告呢?
      3 由于美国密码出口的限制,IE,netscape等浏览器所支持的加密强度是很弱的,如果只采用浏览器自带的加密功能的话,理论上存在被破解可能。
      
      
      八 代理
      下面探讨一下SSL的代理是怎样工作的(可参见[6])。这可能与你开始想的不太一样:)
      当在浏览器里设置了https的代理,而且在浏览器里输入了https://www.example.com之后,
      浏览器会与proxy建立tcp链接,然后向其发出 

       
    展开全文
  • SSL/TLS 原理

    2014-06-17 15:36:10
    首先要澄清一下名字的混淆: 1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。 2 IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为TLS...

    1. 前言

    首先要澄清一下名字的混淆:
    1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。
    2 IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为TLS(Transport Layer Security),从技术上讲,TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别,本文中这两个名字等价。

    我们从各式各样的文章中得知,SSL可以用于保密的传输,这样我们与web server之间传输的消息便是“安全的”。而这种“安全”究竟是怎么实现的,最终有能实现多大程度的保密?本文希望能用通俗的语言阐明其实现原理。

    2. 整体结构概览

    SSL是一个介于HTTP协议与TCP之间的一个可选层,其位置大致如下:

    ---------
    | HTTP |
    ---------
    | SSL |
    ---------
    | TCP |
    ---------
    | IP |
    ---------

    如果利用SSL协议来访问网页,其步骤如下:
    用户:在浏览器的地址栏里输入https://www.sslserver.com
    HTTP层:将用户需求翻译成HTTP请求,如:
    GET /index.htm HTTP/1.1
    Host www.sslserver.com

    SSL层: 借助下层协议的的信道安全的协商出一份加密密钥,并用此密钥来加密HTTP请求。
    TCP层:与web server的443端口建立连接,传递SSL处理后的数据。

    接收端与此过程相反。SSL在TCP之上建立了一个加密通道,通过这一层的数据经过了加密,因此达到保密的效果。

    SSL协议分为两部分:Handshake Protocol和Record Protocol。其中Handshake Protocol用来协商密钥,协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。

    3. 需要的加密方面的基础知识

    了解SSL原理需要一点点加密的概念,这里把需要的概念做一下简单阐述:

    加密一般分为三类,对称加密,非对称加密及单向散列函数。
    对称加密:
    又分分组密码和序列密码。
    分组密码是将明文按一定的位长分组,明文组经过加密运算得到密文组,密文组经过解密运算(加密运算的逆运算),还原成明文组。
    序列密码是指利用少量的密钥(制乱元素)通过某种复杂的运算(密码算法)产生大量的伪随机位流,用于对明文位流的加密。
    解密是指用同样的密钥和密码算法及与加密相同的伪随机位流,用以还原明文位流。

    CBC(Cipher Block Chaining)模式这个词在分组密码中经常会用到,它是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算。当加密算法用于此模式的时候除密钥外,还需协商一个初始化向量(IV),这个IV没有实际意义,只是在第一次计算的时候需要用到而已。采用这种模式的话安全性会有所提高。

    分组密码的典型例子为DES,RC5,IDEA。
    序列密码的典型例子为RC4。
    非对称加密(公钥加密):
    简单的说就是加密密钥与解密密钥不同,分私钥和公钥。这种方法大多用于密钥交换,RSA便是一个我们熟知的例子。还有一个常用的称作DH,它只能用于密钥交换,不能用来加密。
    单向散列函数:
    由于信道本身的干扰和人为的破坏,接受到的信息可能与原来发出的信息不同,一个通用的办法就是加入校验码。单向散列函数便可用于此用途,一个典型的例子是我们熟知的MD5,它产生128位的摘要,在现实中用的更多的是安全散列算法(SHA),SHA的早期版本存在问题,目前用的实际是SHA-1,它可以产生160位的摘要,因此比128位散列更能有效抵抗穷举攻击。

    由于单向散列的算法都是公开的,所以其它人可以先改动原文,再生成另外一份摘要。解决这个问题的办法可以通过HMAC(RFC 2104),它包含了一个密钥,只有拥有相同密钥的人才能鉴别这个散列。

    4. 密钥协商过程

    由于非对称加密的速度比较慢,所以它一般用于密钥交换,双方通过公钥算法协商出一份密钥,然后通过对称加密来通信,当然,为了保证数据的完整性,在加密前要先经过HMAC的处理。

    SSL缺省只进行server端的认证,客户端的认证是可选的。以下是其流程图(摘自TLS协议):

    Client Server

    ClientHello ——–>
    ServerHello
    Certificate*
    ServerKeyExchange*
    CertificateRequest*
    <——– ServerHelloDone
    Certificate*
    ClientKeyExchange
    CertificateVerify*
    [ChangeCipherSpec]
    Finished ——–>
    [ChangeCipherSpec]
    <——– Finished
    Application Data <——-> Application Data

    简单的说便是:SSL客户端(也是TCP的客户端)在TCP链接建立之后,发出一个ClientHello来发起握手,这个消息里面包含了自己可实现的算法列表和其它一些需要的消息,SSL的服务器端会回应一个ServerHello,这里面确定了这次通信所需要的算法,然后发过去自己的证书(里面包含了身份和自己的公钥)。Client在收到这个消息后会生成一个秘密消息,用SSL服务器的公钥加密后传过去,SSL服务器端用自己的私钥解密后,会话密钥协商成功,双方可以用同一份会话密钥来通信了。

    5. 密钥协商的形象化比喻

    如果上面的说明不够清晰,这里我们用个形象的比喻,我们假设A与B通信,A是SSL客户端,B是SSL服务器端,加密后的消息放在方括号[]里,以突出明文消息的区别。双方的处理动作的说明用圆括号()括起。

    A:我想和你安全的通话,我这里的对称加密算法有DES和RC5,密钥交换算法有RSA和DH,摘要算法有MD5和SHA。

    B:我们用DES-RSA-SHA这对组合好了。
    这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份(把证书发给A)。
    目前没有别的可说的了。

    A:(查看证书上B的名字是否无误,并通过手头早已有的CA的证书验证了B的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了B的公钥的真实性)
    (产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量和hmac的密钥。将这份秘密消息——协议中称为 per_master_secret——用B的公钥加密,封装成称作ClientKeyExchange的消息。由于用了B的公钥,保证了第三方无法窃听)
    我生成了一份秘密消息,并用你的公钥加密了,给你(把ClientKeyExchange发给B)
    注意,下面我就要用加密的办法给你发消息了!
    (将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥)
    [我说完了]

    B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了)
    注意,我也要开始用加密的办法给你发消息了!
    [我说完了]

    A: [我的秘密是...]

    B: [其它人不会听到的...]

    6. 加密的计算

    上一步讲了密钥的协商,但是还没有阐明是如何利用加密密钥,加密初始化向量和hmac的密钥来加密消息的。其实其过程不过如此:
    1 借助hmac的密钥,对明文的消息做安全的摘要处理,然后和明文放到一起。
    2 借助加密密钥,加密初始化向量加密上面的消息。

    7. 安全性

    SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论, 目前也有一些成熟的工具如dsniff可以通过man in the middle攻击来截获https的消息。

    从上面的原理可知,SSL的结构是严谨的,问题一般出现在实际不严谨的应用中。常见的攻击就是middle in the middle攻击,它是指在A和B通信的同时,有第三方C处于信道的中间,可以完全听到A与B通信的消息,并可拦截,替换和添加这些消息。

    1 SSL可以允许多种密钥交换算法,而有些算法,如DH,没有证书的概念,这样A便无法验证B的公钥和身份的真实性,从而C可以轻易的冒充,用自己的密钥与双方通信,从而窃听到别人谈话的内容。而为了防止middle in the middle攻击,应该采用有证书的密钥交换算法。
    2 有了证书以后,如果C用自己的证书替换掉原有的证书之后,A的浏览器会弹出一个警告框进行警告,但又有多少人会注意这个警告呢?
    3 由于美国密码出口的限制,IE,netscape等浏览器所支持的加密强度是很弱的,如果只采用浏览器自带的加密功能的话,理论上存在被破解可能。

    8. 关于证书

    注意,如果对于一般的应用,管理员只需生成“证书请求”(后缀大多为.csr),它包含你的名字和公钥,然后把这份请求交给诸如verisign等有CA 服务公司(当然,连同几百美金),你的证书请求经验证后,CA用它的私钥签名,形成正式的证书发还给你。管理员再在web server上导入这个证书就行了。如果你不想花那笔钱,或者想了解一下原理,可以自己做CA。从ca的角度讲,你需要CA的私钥和公钥。从想要证书的服务器角度将,需要把服务器的证书请求交给CA.

    如果你要自己做CA,别忘了客户端需要导入CA的证书(CA的证书是自签名的,导入它意味着你“信任”这个CA签署的证书)。而商业CA的一般不用,因为它们已经内置在你的浏览器中了。





    from: http://www.aitrust.com/ssltls/

    展开全文
  • SSL/TLS/WTLS原理

    2015-09-16 14:21:35
    首先要澄清一下名字的混淆: 1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。 2 IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为TLS...
  • SSL/TLS/WTLS

    2014-03-16 23:20:19
    首先要澄清一下名字的混淆: 1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。 2 IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为T
  • [转帖]SSL/TLS/WTLS原理

    2018-07-05 21:44:00
    SSL/TLS/WTLS原理作者:yawl < yawl@nsfocus.com >主页:http://www.nsfocus.com日期:2001-02-19一 前言首先要澄清一下名字的混淆:1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输...
  • SSL/TLS/WTLS 简单介绍

    2006-12-27 16:59:00
    一 前言首先要澄清一下名字的混淆:1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。2 IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为TLS...
  • 一、首先要澄清一下名字的混淆 1.SSL(Secure Socket Layer)是Netscape公司设计的主要用于WEB的安全传输协议。这种协议在WEB上获得了广泛的应用。 2.IETF将SSL作了标准化,即RFC2246,并将其称为TLS(Transport...
  • [转] SSL/TLS/WTLS原理

    2009-03-26 09:17:00
    最近在研究TLS,找到一篇不错的文章,转过来以便学习,本人不负任何责任。 SSL/TLS/WTLS原理 作者:yawl <...首先要澄清一下名字的混淆: 1 SSL(Secure Socket Layer)是netscape公司设计的主...
  • 一、首先要澄清一下名字的混淆1.SSL(Secure Socket Layer)是Netscape公司设计的主要用于WEB的安全传输协议。这种协议在WEB上获得了广泛的应用。2.IETF将SSL作了标准化,即RFC2246,并将其称为TLS(Transport Layer ...
  • SS端加密以及obfs混淆推荐

    万次阅读 2019-08-26 20:59:19
    SS端加密以及obfs混淆 ...(排名分先后)推荐的混淆obfs:首选http、次选tls ​ 注:加密方式推荐是因为AEAD本身有新的特性,另外主推荐aes-256-gcm是因为这个加密实测多数主流设备下都可以通过硬件加解...

空空如也

空空如也

1 2 3 4
收藏数 77
精华内容 30
关键字:

tls混淆