녹색 자물쇠 설명: SSL 핸드셰이크는 어떻게 작동합니까?

매일 보안을 염두에 두고 웹을 검색할 때 브라우저의 웹 사이트 URL 주소와 데이터 전송 프로토콜의 HTTPS 버전 근처에 있는 유명한 녹색 자물쇠에 대해 생각합니다. 이 기사에서는 HTTPS가 실제로 안전한 이유 와 통신이 제3자의 도청으로부터 어떻게 보호되는지 알아보겠습니다 .

먼저 디지털 서명 과 암호화 라는 두 가지 기본 암호화 개념을 간략하게 소개하고 클라이언트와 서버가 통신 교환을 시작하기 전에 수행되고 안전한 암호화 컨텍스트를 설정하는 데 사용되는 SSL 핸드셰이크 라는 프로세스에 대해 알아보겠습니다. 클라이언트 인증서 인증이라는 선택적 단계를 통해 보안을 더욱 강화하는 방법에 대한 정보를 마치겠습니다.

공개 키 암호화 101: 키 쌍

개인 메시지를 안전하게 교환하기 위해 암호화 방식을 사용하기로 결정한 두 사람 앨리스와 밥을 만나보세요. 그들이 직면해야 하는 첫 번째 선택은 대칭 및 비대칭 키 암호화 (공개 키 암호화라고도 함)라는 두 가지 다른 암호화 유형 중에서 선택하는 것입니다.

하지만 잠깐, 이 열쇠들은 무엇 입니까? 기본적으로 키가 임의의 문자 시퀀스라는 것을 단순화할 수 있습니다. 이 시퀀스를 사용하여 메시지를 변환(특정 암호화 작업 수행)할 수 있습니다. 곧 자세히 살펴보겠습니다.

대칭 키 암호화

대칭 키 암호화를 사용할 때 발신자는 키를 생성한 다음 수신자를 위해 키를 복제합니다 . 발신자는 원본 키를 저장하고 사본은 수신자에게 전달됩니다. 통신의 양쪽 끝에서 암호화 작업에 동일한 키가 사용됩니다.

그리고 대칭 키 암호화의 주요 장점과 단점은 무엇입니까?

비대칭 키 암호화

비대칭 키 암호화를 사용할 때 발신자와 수신자 모두 공개 키와 개인 키라는 키 쌍을 생성합니다 . 키는 수학적으로 서로 결합되어 다양한 암호화 작업에서 함께 작동합니다. 발신자와 수신자 모두 개인 키를 안전하게 저장하지만 특별한 예방 조치 없이 공개 키를 교환할 수 있습니다. 그들은 일종의 "공개 키 옐로우 페이지"를 사용할 수도 있습니다. 공개 키 서버를 사용하여 누구나 액세스할 수 있도록 공개 키를 보낼 수도 있습니다.

비대칭 키 암호화의 장단점은 무엇입니까?

비대칭 암호화 설정이 더 안전하기 때문에 Alice와 Bob은 이를 사용하기로 결정했습니다! 이제 그들은 이를 활용하고 통신의 보안 및 무결성 보장에 대해 생각할 수 있습니다.

공개 키 암호화 101: 암호화

Alice가 Bob에게 메시지를 보낼 때 그녀는 내용이 무엇인지 다른 사람이 볼 수 없도록 하려고 합니다. 그녀는 메시지를 암호화하기로 결정합니다. 이를 달성하기 위해 Alice는 먼저 키 서버에서 또는 통신 채널을 통해 Bob으로부터 직접 Bob의 공개 키를 가져와야 합니다. Alice가 키를 얻은 후에는 전송하려는 메시지에 Bob의 공개 키를 사용하여 암호화 작업을 적용할 수 있습니다 .

일반적으로 이 프로세스에서 메시지는 블록(가장 일반적으로)의 암호화 알고리즘(일명 암호)에 의해 수행되고 메시지와 키 사이의 일부 비트 연산이 수행되어 암호화된 메시지(일명 암호문)인 출력을 생성합니다. . Bob이 암호화된 메시지를 받으면 자신의 개인 키로 암호를 해독할 수 있는 유일한 사람입니다.

메모:

• 메시지 암호화 – 발신자는 수신자 공개 키로 메시지를 암호화합니다.
• 메시지 복호화 – 수신자가 자신의 개인 키로 메시지를 복호화

공개 키 암호화 101: 서명

메시지 내용이 노출되는 것을 방지하는 것 외에도 보낸 사람의 신원을 확인하고 메시지가 변경되지 않았는지 확인하는 것도 똑같이 중요합니다. 디지털 서명 (메시지에 첨부된 별도의 개체)은 정확히 이 두 가지 이유로 사용됩니다.

Alice는 먼저 해싱 알고리즘을 사용하여 메시지 해시를 개발하여 서명을 생성합니다. 해싱은 다른 입력에 대해 다른 더 짧은 고정 값 출력을 생성하는 메시지에 대한 단방향 수학 함수를 계산하는 것입니다. 그런 다음 그녀는 자신의 개인 키 를 사용하여 생성된 해시를 암호화 (서명)합니다.

다음으로 Bob이 메시지와 서명을 받으면 먼저 Alice의 공개 키 를 사용하여 서명을 해독 할 수 있습니다. 성공하면 서명이 실제로 Alice에 의해 생성되었음을 알게 됩니다(그렇지 않으면 그녀의 공개 키로 암호 해독이 실패함).

둘째, Bob은 Alice가 이전에 사용했던 것과 동일한 알고리즘을 사용하여 메시지를 가져와 해시할 수 있으며 메시지의 해시가 Alice가 생성한 것과 동일한지 확인할 수 있습니다. 해시가 일치하면 메시지가 변조되지 않았음을 알 수 있습니다.

메모:

• 서명 생성 – 발신자는 자신의 개인 키로 메시지 해시를 암호화(서명)하고 서명을 생성합니다.
• 서명 확인 – 수신자는 먼저 서명의 메시지 해시를 해독하고 자신이 계산한 해시가 서명의 해시와 일치하는지 확인합니다.
• 암호화와 서명은 별도로 사용할 수 있지만 최상의 보안을 위해 일반적으로 결합됩니다. 따라서 만날 수 있는 대부분의 암호화 함수는 encryptSignMessage() , decryptVerifyMessage() 등입니다.

Alice & Bob 이야기를 따라가는 데 어려움이 없으시길 바랍니다. 모든 것이 명확하고 요약하기 위해 전체 흐름을 다시 한 번 설명하겠습니다.

1. Alice는 Bob에게 메시지를 보내고 싶어합니다.
2. Alice는 개인 키를 가져 와서 서명을 생성합니다.
3. Alice는 Bob의 공개 키를 가져와 메시지를 암호화합니다.
4. Alice는 Bob에게 메시지를 보냅니다.
5. Bob은 Alice의 공개 키를 가져오고 서명을 확인합니다.
6. Bob은 자신의 개인 키를 사용하여 메시지를 해독합니다.

좋아, 이론으로 충분하다. 이제 이 모든 것이 HTTPS에서 어떻게 사용되는지 봅시다!

SSL 핸드셰이크

인사해 주세요

클라이언트가 서버에 대한 연결을 시작하면 먼저 나머지 통신에 대한 암호화 컨텍스트를 설정하기 위해 적절한 소개를 하는 것이 중요합니다. 이것은 헤더 및 요청 본문을 구문 분석하기 전에 HTTPS CONNECT 단계에서 수행할 수 있습니다. 모든 것은 클라이언트 가 클라이언트에게 Hello 메시지를 보내는 것으로 시작됩니다.

가장 중요한 것은 메시지에는 클라이언트가 이해하는 암호화 알고리즘과 지원되는 압축 알고리즘, 프로토콜 버전, 세션 ID 등과 같은 추가 자료가 포함되어 있다는 것 입니다. 서버 공개 키가 있는 서버 인증서가 포함되어 있습니다(예, 프로세스는 공개 키 암호화를 기반으로 합니다. Alice와 Bob이 선택한 것과 동일한 방법).

인증 기관

이제 무대에서 다음 손님인 인증 기관 (CA)을 환영할 시간입니다. 이름은 진지하게 들리지만 기본적으로 전 세계적으로 신뢰할 수 있는 것으로 간주되는 많은 거리 크레딧을 보유한 제3자 업체일 뿐입니다. 이러한 엔터티는 서버의 ID를 확인하고 서버 인증서와 함께 디지털 서명을 배치할 수 있습니다(Bob에게 메시지를 보낼 때 Alice와 유사).

인증서 확인

이제 마지막으로 브라우저의 URL 주소 옆에 있는 제목 녹색 자물쇠 를 살펴보겠습니다.

각 웹 클라이언트에는 잘 알려져 있고 신뢰할 수 있는 인증 기관의 공개 키 번들 목록이 있습니다. 기사 시작 부분에서 서명은 보낸 사람의 개인 키를 사용하여 생성되고 보낸 사람의 공개 키를 사용하여 확인할 수 있다고 언급한 것을 기억할 수 있습니다. 이것이 바로 클라이언트가 하는 일 입니다. 번들로 제공되는 신뢰할 수 있는 CA 목록을 통해 서버 인증서의 서명이 신뢰할 수 있는 CA 중 하나에 속하는지 확인합니다. 그렇다면 인증서를 수락 하고 자물쇠가 녹색으로 바뀌는 순간입니다.

그러나 이는 아직 보안과 관련이 없는 첫 번째 단계에 불과합니다. 누구나 공개 키 인증서를 복사하여 서버에 저장하고 연결하는 클라이언트에 제공할 수 있습니다. 그렇죠?

클라이언트는 서버 인증서를 확인한 후 대칭 키 를 만들어 통신을 암호화합니다. 그러나 서두에 언급했듯이 대칭 키의 문제는 전송 중에 가로채기 쉽다는 것입니다. 이 단계에서 클라이언트와 서버에는 공통 암호화 컨텍스트가 없습니다. 따라서 클라이언트는 대칭 키를 서버에 보내지만 먼저 서버의 공개 키로 암호화합니다. 그런 다음 서버는 이를 수신하고 보안 연결을 설정하기 위해 암호를 해독하는 기능이 필요합니다.

따라서 누군가 도난당한 공개 키 인증서 를 제시하더라도 실패할 단계입니다. 서버 인증서 공개 키에 바인딩된 유효한 개인 키는 대칭 키를 해독하는 데 필수적입니다. 물론 합법적인 서버에는 개인 키가 안전하게 저장되어 있기 때문에 문제가 되지 않습니다. 대칭 키를 해독하고 추가 통신을 암호화하는 데 사용할 수 있습니다.

요약 하자면 SSL 핸드셰이크는 대칭 및 비대칭 암호화 유형이 모두 사용되는 프로세스입니다 . 처음에는 비대칭 키 쌍이 연결을 시작하고 대칭 키가 이동할 수 있는 안전한 방법을 제공합니다. 처음에 지적했듯이 대칭 암호화 작업이 더 빠르므로 설정 후 전체 통신에 사용하는 것이 좋습니다. 또한 보안 연결이 설정되면 만료될 때까지 재사용하므로 클라이언트가 요청할 때마다 비대칭 키 설정이 수행되지 않습니다.

실생활에서 인증서는 가장 유명한 신뢰할 수 있는 CA ( root 라고 함)에서 직접 서명하지 않는다는 점도 언급할 가치가 있습니다. 그래도 루트 CA는 중간 인증서에 서명한 다음 최종적으로 서버 인증서에 서명합니다. 따라서 연결 클라이언트가 유효한 서명이 충족될 때까지 확인하는 인증서 체인을 만듭니다. 확실히 더 나은 보안을 제공합니다. 중간 CA 중 하나가 손상되면 더 적은 수의 사람들에게 영향을 미칩니다.

클라이언트 인증서 유효성 검사

이제, 우리가 그것을 이해하는 데 필요한 모든 지식을 가지고 있으므로 간단히 언급할 수 있는 하나의 선택적 단계가 있습니다. 추가 보안을 달성하기 위해 보안 연결을 설정한 후 클라이언트 인증서를 요청하고 유효성을 검사하도록 서버를 구성할 수 있습니다.

동일한 방식으로 작동하지만 이번에 는 클라이언트가 인증서를 보내고 서버가 신뢰할 수 있는 인증 기관 목록을 살펴보고 확인합니다. 또한 서버가 개발자의 제어 하에 있으므로(클라이언트, 즉 웹 브라우저 또는 모바일 운영 체제와 반대) 백엔드 개발자가 신뢰할 수 있는 인증서 목록을 쉽게 수정할 수 있습니다.

기업 네트워크는 일반적으로 이 메커니즘을 사용합니다. 대부분의 경우 클라이언트 인증서는 직원 장치에 설치된 장치 관리 시스템에서 생성되며 회사에서 생성한 루트 인증서로 서명됩니다. 동일한 인증서가 백엔드 환경에도 추가됩니다. 이렇게 하면 클라이언트가 연결할 때 회사 백엔드에서 인증서를 쉽게 확인할 수 있습니다.

백엔드 솔루션을 살펴보겠습니다.

더 읽기

이제 요약하자면 전체 흐름에 대한 다이어그램을 살펴보겠습니다.

요약

기사의 끝에 도달했습니다! HTTPS에서 암호화 설정 의 구현 메커니즘과 서명 및 암호화 프로세스의 응용 방법을 이미 이해하셨기를 바랍니다.

작동 방식을 알고 있으므로 데이터 암호화에 대해 더 확신을 가져야 합니다. 그러나 브라우저의 녹색 자물쇠가 아직 안전을 보장하지 않는다는 점을 기억하는 것이 중요합니다. 보안에 민감한 컨텍스트에서는 인증서도 자세히 조사해야 합니다. 그들이 말했듯이, 사전 경고는 팔뚝입니다!