텍스트 컨텐츠, 텍스트의 원래 작성자에게 감사 - "깊이의 층에 대한 질문 HTTPS를 원칙 분석"이 문서는 저자 "leapMie의"를 의미합니다.
1 소개
심지어 1 년, 애플은 애플 APP 응용 프로그램 시장의 전제 조건 선반 중 하나 (로 HTTPS를 흔히 사용되는 인터넷 안전에 대한 인식의 일반 증가, 애플리케이션의 높은 보안 요구 사항, HTTPS 사용으로 참조 : " 애플은 ATS를 시행하는 것입니다, 당신은 HTTPS APP 아직로 전환 할 준비가 되셨나요? ").
그래서, 인스턴트 메시징 또는 다른 IM 애플리케이션, 향상된 네트워크 보안 인식 오늘날 많은 장면은 확실히 올바른 HTTPS 사용 여부. HTTPS 결국 대칭 암호화 또는 비대칭 암호화를 사용하여 : IM,이 틀림없이 TLS와 긴 연결 문제없이 HTTPS 짧은 연결,하지만 메시징 인스턴트의 개발자를 위해 가장 기본적인의 얼굴로, 당신에게 질문을 물어보고 싶은 ?
이 질문에 대답하기 위해, 분명히 HTTPS,이 대칭 암호화 또는 비대칭 암호화를 사용하여 결국 HTTPS를 통해 당신을 데려 갈 것이다 기사와 특별히 그들이 어떻게 사용의 기술적 원칙을 정렬 할 필요가있다.
학습 거래소 :
- IM / 푸시 기술 개발 및 환 5 그룹 : 215 477 170 [추천]
- 끝 모바일 IM 개발 소개 기사 : " 시작하기 하나는 충분하다 : 0에서 모바일 끝을 개발하기 위해 IM "
(동기에 발표 된이 문서 : http://www.52im.net/thread-2866-1-1.html )
2. 관련 기사
➊ HTTP 프로토콜을 이해해야합니다, HTTPS 이해하기 위해, 다음과 같은 기사가있을 수 있습니다 당신은 필요 :
" 네트워크 게으른 항목 (VII)을 프로그래밍 : 간단한 용어, HTTP 프로토콜의 포괄적 인 이해를 ."
" 뇌사 네트워크 프로그래밍 항목 (III) : HTTP 지식이 될 것입니다 알고 있어야합니다 프로토콜 "
" 알 네트워크 프로그래밍 (VIII) 다음 HTTP 깊이로부터 전송 된 데이터를 해독 "
" HTTP에 HTTP / 0.9 / 2 : HTTP 프로토콜은 역사의 진화와 디자인 아이디어의 텍스트를 읽을 수 있습니다 ."
" 웹 소켓은 상세 (D) : HTTP와 웹 소켓 (파트 I)의 호기심 관계 "
" 웹 소켓 댓글 (오) : 관계 호기심 HTTP 및 웹 소켓 (파트 II) "
" 나는 인터뷰를 망칠 수 있습니다 마 당신은 그것을 시작할 수있는 TCP 연결 HTTP 요청의 수를 알아? "
HTTPS ➋의 지식은 내가 읽어 보시기 바랍니다, 더 나은이 문서를 이해하려면 다음 HTTPS 함께 자료 문서와 :
" 1 분 HTTPS 결국 해결하기 위해 어떤 문제를 이해하기 "
" IM 보안 서류 (칠) :이 HTTPS 이해하는 경우, 하나는 충분하다 ."
" 하나는 HTTPS 읽어 등 암호화 원리, 논리적 보안, 디지털 인증서를 "
➌이 기사는 기사 (8)의 첫 번째 시리즈는,이 시리즈의 목록은 다음과 같이 보안 IM 통신 지식 :
" IM 보안 용지 (A) : 올바르게 이해하고 안드로이드 사이드 암호화 알고리즘을 사용하는 "
" IM 보안 서류 (두) : IM 암호화 알고리즘의 조합을 알아보고자 하였다 "
" IM 보안 용지 (3 개) : 일반적으로 사용되는 암호화 및 암호 해독 알고리즘과 설명하는 통신 보안 ."
" IM 보안 용지 (D) : 리스크 분석 안드로이드의 예 키 하드 코딩 "
" IM 보안 서류 (V) : 안드로이드 플랫폼에 연습에 대칭 암호화 기술 ."
" IM 보안 서류 (육) : 원칙과 비대칭 암호화 기술의 적용 ."
" IM 보안 서류 (칠) :이 원리를 HTTPS 이해하는 경우, 하나는 충분하다 ."
" IM 보안 장 (VIII) : 당신은, HTTPS 암호화 대칭 또는 비대칭 암호화를 사용하여 알아? "(조)
3, HTTPS 고문 영혼
에서 HTTPS 비용의 감소의 설립, 현재 대부분의 사이트가 이미 HTTPS 프로토콜을 지출하기 시작했다으로. HTTP보다 HTTPS 보안, 또한 HTTPS 프로토콜과 관련된 개념을 들어 본 것을 우리 모두는 알고는 SSL, 비대칭 암호화, CA 인증서가 있습니다.
그러나 다음과 같은 세 가지 고문 영혼에 대답하지 않을 수 있습니다 :
- 1) 왜 HTTPS를 안전하게 사용할 수 있습니까?
- 2) HTTPS 구현하는 방법 기본 원칙?
- 3) 확실히 안전한 HTTPS를 사용하고 계십니까?
걱정하지 마세요,이 문서는 "대칭 암호화 또는 비대칭 암호화를 사용하여 결국 HTTPS를?"대답 할 것이다, 드라이브 집 HTTPS의 보안의 원칙에서 깊이의 층이, 당신은 또한 문제는 위에서 설명한 이해할 수 있지만.
HTTPS의 4 원칙
당신은 HTTPS 프로토콜 이유를 들어있을 수 있습니다 이유는 데이터가 보안 HTTPS 전송 프로토콜이 암호화됩니다이지만, 암호화 프로세스 비대칭 암호화 구현을 사용하기 때문이다. 그러나 사실 : HTTPS 전송에서 사용하기 위해 암호화 된 내용은 대칭 암호화에만 자격 검증 단계에서 행동하는 비대칭 암호화입니다.
전체 프로세스는 인증서 인증 및 데이터 전송 단계는, 특정 상호 작용은 다음과 같은된다 HTTPS로 분할된다 :
① 자격 검증 단계 :
1) HTTPS 브라우저 요청을 시작;
2) HTTPS 서버 인증서를 반환
3）客户端验证证书是否合法，如果不合法则提示告警。
② 数据传输阶段：
1）当证书验证合法后，在本地生成随机数；
2）通过公钥加密随机数，并把加密后的随机数传输到服务端；
3）服务端通过私钥对随机数进行解密；
4）服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。
5、为什么数据传输是用对称加密？
首先：非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。
另外：在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。
6、为什么需要 CA 认证机构颁发证书？
HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。
首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。
“中间人攻击”的具体过程如下：
如上图所以，过程原理如下：
- 1）本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器；
- 2）中间人服务器返回中间人自己的证书；
- 3）客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输；
- 4）中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密；
- 5）中间人以客户端的请求内容再向正规网站发起请求；
- 6）因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据；
- 7）中间人凭借与正规网站建立的对称加密算法对内容进行解密；
- 8）中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输；
- 9）客户端通过与中间人建立的对称加密算法对返回结果数据进行解密。
由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。
7、浏览器是如何确保 CA 证书的合法性？
7.1 证书包含什么信息？
- 1）颁发机构信息；
- 2）公钥；
- 3）公司信息；
- 4）域名；
- 5）有效期；
- 6）指纹；
- 7）......
7.2 证书的合法性依据是什么？
- 1）首先：权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构；
- 2）另外：证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。
所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。
7.3 浏览器如何验证证书的合法性？
浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：
1）验证域名、有效期等信息是否正确：证书上都有包含这些信息，比较容易完成验证；
2）判断证书来源是否合法：每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证（如下图所示）：
3）判断证书是否被篡改：需要与 CA 服务器进行校验；
4）判断证书是否已吊销：通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率。
以上任意一步都满足的情况下浏览器才认为证书是合法的。
这里插一个我想了很久的但其实答案很简单的问题：
既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？
其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。
7.4 只有认证机构可以生成证书吗？
如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的 HTTPS 传输。
例如早期的 12306 采用的便是手动安装私有证书的形式实现 HTTPS 访问：
8、本地随机数被窃取怎么办？
证书验证是采用非对称加密实现，但是传输过程是采用对称加密，而其中对称加密算法中重要的随机数是由本地生成并且存储于本地的，HTTPS 如何保证随机数不会被窃取？
其实 HTTPS 并不包含对随机数的安全保证，HTTPS 保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。
9、用了 HTTPS 会被抓包吗？
HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。
但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。
既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？
HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。
10、本文小结
以下用简短的Q&A形式进行全文总结。
Q: HTTPS 为什么安全？
A: 因为 HTTPS 保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。
Q: HTTPS 的传输过程是怎样的？
A: 客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。
Q: 为什么需要证书？
A: 防止”中间人“攻击，同时可以为网站提供身份证明。
Q: 使用 HTTPS 会被抓包吗？
A: 会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。
好了，回归到本文标的问题，我们来总结回顾一下。
Q: HTTPS用的是对称加密还是非对称加密？
Q: HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。
顺手 po 一张学习的过程图（点击查看大图）：
附录：更多有关IM安全的文章
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
《Web端即时通讯安全：跨站点WebSocket劫持漏洞详解(含示例代码)》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《即时通讯安全篇（七）：如果这样来理解HTTPS原理，一篇就够了》
《即时通讯安全篇（八）：你知道，HTTPS用的是对称加密还是非对称加密？》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2866-1-1.html）