대기업 인터뷰 : HTTPS를 3번 연속으로 물어봤고, 마지막 질문은 사람이 많은지 여부였습니다.

안녕하세요 여러분, 유용한 정보를 전문적으로 공유하는 라오티안입니다. 그리고 인터뷰 자료가 필요한 친구들은 백스테이지에서 꼭 답장해주세요面试

Foreword

HTTPS가 HTTP보다 안전하다는 것은 누구나 알고 있고, HTTPS와 관련된 개념도 들어본 적이 있을 것입니다. 프로토콜에는 SSL, 비대칭 암호화, CA 인증서 등이 포함됩니다.

그러나 다음 세 가지 영혼 고문 질문에 답하지 못할 수도 있습니다.

• HTTPS는 왜 안전한가요?
• HTTPS의 기본 원칙을 어떻게 구현하나요?
• HTTPS를 사용하는 것이 반드시 안전한가요?

이 글에서는 HTTPS의 보안을 원칙적으로 자세히 설명합니다.

HTTPS의 구현 원리

HTTPS 프로토콜이 안전한 이유는 HTTPS 프로토콜이 전송되는 데이터를 암호화하고, 암호화 과정에서 비대칭 암호화를 사용하기 때문이라는 말을 들어보셨을 것입니다.

그러나 실제로 HTTPS는 대칭 암호화를 사용하여 콘텐츠 전송을 암호화하며, 비대칭 암호화는 인증서 확인 단계에서만 작동합니다.

HTTPS의 전체 프로세스는 인증서 확인 및 데이터 전송 단계로 구분됩니다. 구체적인 상호 작용 프로세스는 다음과 같습니다.

img

인증서 확인 단계:

• 브라우저가 HTTPS 요청을 시작합니다.
• 서버가 HTTPS 인증서를 반환합니다.
• 클라이언트는 인증서가 적법한지 확인하고, 적법하지 않은 경우 알람을 표시합니다.

데이터 전송 단계:

• 인증서가 적법한 것으로 확인되면 로컬에서 임의의 숫자가 생성됩니다.
• 공개키를 통해 난수를 암호화하고, 암호화된 난수를 서버로 전송합니다.
• 서버는 개인 키를 통해 난수를 해독합니다.
• 서버는 클라이언트가 전달한 난수를 통해 대칭 암호화 알고리즘을 구성하고, 반환된 결과 내용을 암호화하여 전송합니다.

데이터 전송에 대칭 암호화를 사용하는 이유는 무엇인가요?

무엇보다도 비대칭 암호화의 암호화 및 복호화 효율성은 매우 낮으며, HTTP 응용 시나리오에서는 일반적으로 종단 간 상호 작용이 많기 때문에 비대칭 암호화의 효율성은 용납할 수 없습니다.

또한 HTTPS 시나리오에서는 서버만 개인 키를 저장하며 공개 키와 개인 키 쌍은 단방향 암호화 및 복호화만 달성할 수 있습니다. 따라서 HTTPS의 콘텐츠 전송 암호화는 비대칭 암호화 대신 대칭 암호화를 채택합니다. 암호화.

인증서 발급에 CA 인증기관이 필요한 이유는 무엇인가요?

HTTP 프로토콜은 전송 프로세스가 수신기에 의해 쉽게 연결되어 서버를 모니터링하고 위조할 수 있기 때문에 안전하지 않은 것으로 간주되는 반면, HTTPS 프로토콜은 주로 네트워크 전송의 보안 문제를 해결합니다.

먼저, 인증 기관이 없고 누구나 인증서를 만들 수 있다고 가정합니다. 이로 인해 발생하는 보안 위험은 전형적인 "중간자 공격" 문제입니다.

"중간자 공격"의 구체적인 프로세스는 다음과 같습니다.

프로세스 원칙은 다음과 같습니다.

• 로컬 요청이 하이재킹됩니다(예: DNS 하이재킹 등). ), 모든 요청은 중개인 서버로 전송됩니다.
• 중개자 서버는 중개자 자신의 인증서를 반환합니다.
• 클라이언트는 난수를 생성하고 중개자 인증서의 공개키를 통해 난수를 암호화하여 중개자에게 전송한 후, 난수를 사용하여 대칭 암호화를 구성하여 전송 내용을 암호화합니다.
• 중개자는 클라이언트의 난수를 가지고 있기 때문에 대칭 암호화 알고리즘을 통해 콘텐츠를 복호화할 수 있습니다.
• 중개자는 클라이언트의 요청 콘텐츠를 사용하여 일반 웹사이트에 대한 요청을 시작합니다.
• 중개자와 서버 사이의 통신 과정은 적법하기 때문에 일반 웹사이트에서는 확립된 보안 채널을 통해 암호화된 데이터를 반환합니다.
• 중개인은 합법적인 웹사이트에서 구축한 대칭 암호화 알고리즘을 사용하여 콘텐츠를 해독합니다.
• 중간자는 클라이언트와 함께 설정한 대칭 암호화 알고리즘을 통해 일반 콘텐츠에서 반환되는 데이터를 암호화하여 전송합니다.
• 클라이언트는 반환된 결과 데이터를 중개자와 구축한 대칭 암호화 알고리즘을 통해 복호화합니다.

인증서 확인 부족으로 인해 클라이언트가 HTTPS 요청을 시작하더라도 클라이언트는 네트워크가 가로채어졌고 모든 전송 콘텐츠가 중개자에 의해 도난당했다는 사실을 전혀 모릅니다.

브라우저는 CA 인증서의 적법성을 어떻게 보장하나요?

인증서에는 어떤 정보가 담겨 있나요?

인증서에는 다음 정보가 포함되어 있습니다.

• 기관 정보
• 공개 키
• 회사 정보
• 도메인 이름
• 유효 기간
• 지문
• …

증명서 근거는 무엇인가요? 적법성을 위해?

우선, 권위 있는 기관은 인증을 받아야 합니다. 아무 기관이나 인증서를 발급할 자격이 있는 것은 아닙니다. 그렇지 않으면 권위 있는 기관이라고 할 수 없습니다.

또한, 인증서의 신뢰성은 신뢰 시스템을 기반으로 합니다. 권위 있는 기관이 발행한 인증서인 한, 우리는 이를 합법적인 것으로 간주합니다.

그래서 권위 있는 기관은 지원자의 정보를 검토합니다. 수준에 따라 권위 있는 기관마다 검토 요구 사항이 다르기 때문에 인증서도 무료, 저가, 고가로 나뉩니다.

브라우저는 인증서의 적법성을 어떻게 확인하나요?

브라우저가 HTTPS 요청을 시작하면 서버는 웹사이트의 SSL 인증서를 반환합니다.

브라우저는 인증서에 대해 다음 확인을 수행해야 합니다.

• 도메인 이름, 유효 기간 및 기타 정보가 올바른지 확인하세요. 인증서에는 이 정보가 포함되어 있어 확인을 더 쉽게 완료할 수 있습니다.
• 인증서의 출처가 합법적인지 확인하세요. 발급된 각 인증서는 검증 체인에 따라 해당 루트 인증서를 찾을 수 있습니다. 운영 체제와 브라우저는 권한 있는 기관의 루트 인증서를 로컬로 저장하여 해당 기관에서 발급한 인증서의 소스 확인을 완료할 수 있습니다. 조직.

• ** 인증서가 변조되었는지 확인합니다. **CA 서버 확인이 필요합니다.

• ** 인증서가 해지되었는지 확인합니다. **CRL(인증서 해지 목록) 및 OCSP(온라인 인증서 상태 프로토콜)를 통해 달성됩니다.

  3단계에서 OCSP를 사용하면 CA 서버와의 상호작용을 줄이고 검증 효율성을 높일 수 있습니다.

위 단계 중 하나라도 충족된 경우에만 브라우저는 인증서가 합법적인 것으로 간주합니다.

**여기에 제가 오랫동안 생각해 왔던 질문이 있지만 대답은 실제로 매우 간단합니다. **인증서는 공개이므로 중간자 공격을 시작하려면 인증서를 다운로드합니다. 공식 웹사이트의 인증서를 내 서버 인증서로 사용하면 클라이언트는 이 인증서가 합법적이라는 점에 확실히 동의하게 됩니다. 인증서의 부정한 사용을 방지하는 방법은 무엇입니까?

실제로 이는 암호화되지 않은 대칭 공개 키와 개인 키를 사용하는 것입니다. 중개자는 인증서를 얻을 수 있지만 개인 키는 얻을 수 없습니다.

중개자가 인증서를 획득하더라도 클라이언트가 전달한 암호화된 데이터를 해독할 수 없기 때문에 해당 개인 키를 추론하는 것은 불가능합니다.

인증 기관에서만 인증서를 생성할 수 있나요?

보안 위험에 대한 메시지가 표시되지 않도록 브라우저가 필요한 경우 인증 기관에서 발급한 인증서만 사용할 수 있습니다.

그러나 브라우저는 일반적으로 보안 위험에 대한 메시지만 표시하고 웹 사이트에 대한 액세스를 제한하지 않으므로 기술적으로 누구나 인증서를 생성할 수 있으며 인증서가 있는 한 웹 사이트의 HTTPS 전송을 완료할 수 있습니다.

예를 들어 초기 12306에서는 HTTPS 액세스를 달성하기 위해 개인 인증서를 수동으로 설치했습니다.

지역난수를 도난당한 경우 어떻게 해야 하나요?

인증서 검증은 비대칭 암호화를 사용하여 구현되지만 전송 프로세스는 대칭 암호화를 사용하며 대칭 암호화 알고리즘의 중요한 난수는 로컬에서 생성되어 저장됩니다. HTTPS는 난수가 도용되지 않도록 어떻게 보장합니까?

실제로 HTTPS에는 난수에 대한 보안 보장이 포함되어 있지 않습니다. HTTPS는 전송 프로세스의 보안만 보장하며, 난수는 로컬에 저장됩니다. 대책에는 바이러스 백신 소프트웨어 설치가 포함됩니다. 트로이 목마 방지, 버그 수정을 위한 서버 업그레이드 등

HTTPS를 사용하면 패킷이 캡처되나요?

HTTPS 데이터는 암호화되어 있습니다. 일반적인 상황에서는 프록시 요청 후 패킷 캡처 도구로 캡처한 패킷 콘텐츠가 암호화되어 직접 볼 수 없습니다.

그러나 위에서 언급한 것처럼 브라우저는 사용자가 승인하는 경우에만 보안 위험 메시지를 표시하며 계속해서 웹사이트에 액세스하여 요청을 완료할 수 있습니다.

因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。

通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互。

然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。

要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。

总结

以下用简短的 Q&A 形式进行全文总结：

Q：HTTPS 为什么安全？

A：因为 HTTPS 保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。

Q：HTTPS 的传输过程是怎样的？

A：客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数。

通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。

Q：为什么需要证书？

A：防止“中间人”攻击，同时可以为网站提供身份证明。

Q：使用 HTTPS 会被抓包吗？

A：会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

顺手分享一张学习 HTTPS 的过程图：

위 내용은 대기업 인터뷰 : HTTPS를 3번 연속으로 물어봤고, 마지막 질문은 사람이 많은지 여부였습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!