[Frontend_Roadmap] HTTPS 작동 방식
오늘은 HTTPS가 무엇이고 어떻게 작동하는지에 대해 만화를 통해 배워보겠습니다.
How HTTPS Works
🙀 A cat explains how HTTPS works...in a comic! 😻
howhttps.works
HTTPS가 필요한 이유 3가지
- 개인정보 보호
- 무결성
- 식별
1. 개인정보 보호
개인 정보 보호란 아무도 메세지를 가로챌 수 없음을 의미합니다. 만약 우리가 HTTPS 없이 웹 사이트를 탐색한다면, 비밀번호를 도청당할 수도 있습니다...! 브라우저의 URL 표시 옆에 자물쇠는 몰래 훔쳐보고 있는 크랩이 없다는 것을 의미합니다.
2. 무결성
무결성이란, 메세지가 목적지로 가는 도중 조작되지 않았음을 의미합니다.
3. 식별
식별은 내가 받은 메세지가 컴퍼그터(발신자)로 부터 온 것을 확인할 수 있는 것을 의미합니다. 메세지에 첨부된 디지털 서명은 발신자를 확인 할 수 있습니다.
또한, 웹을 탐색할 때 식별은 방문하는 사이트가 우리가 실제로 생각하는 그 사이트임을 의미합니다. HTTPS는 SSL 인증서를 통해 우리가 예상한 수신자에게 정확하게 전달해줍니다.
대칭 키와 비대칭 키 알고리즘
HTTPS는 앞서 말한 3가지를 제공할 방법이 필요한데, 바로 그 방법이 암호화 메커니즘입니다.
1. 대칭 키
내가 보낼 메세지를 대칭 키를 사용해서만 열 수 있는 상자에 넣고 상대방에게 전달합니다. 그럼 상대방은 해당 키를 가지고 있어야지만 상자를 열고 메세지를 볼 수 있겠죠? 때문에 키를 비공개로 유지하는 것이 중요합니다. 누군가 가로챈다면? 상자에 접근할 수 있게 되어버리니깐요... 대칭 키의 주요한 문제는 공유가 어렵다는 점입니다. 그래서 비대칭 키라는 것을 만들게 되었습니다!
2. 비대칭 키
비대칭 키는 2개의 키를 갖는다. 우선 공개 키로 메세지를 암호화하고 이를 해독하기 위해 각자가 가지고 있는 비공개 키로만 해독할 수 있습니다. 위 방법은 개인 정보 보호 뿐만 아니라 식별에도 유용합니다.
다음은 SSL을 사용하여 사이트를 연결할 때, 대칭 및 비대칭 키가 어떻게 동작하는지 알아봅시다.
핸드 셰이크
URL 옆에 자물쇠는 어떻게 작동하는 것일까요? 이 사이트를 예로 들어봅시다. 사용자의 브라우저는 이 블로그가 호스팅 되는 서버와 통신했으며 양쪽 다 메세지 전송을 위한 보안 연결을 설정했습니다. 그러나 먼저 서버와 브라우저는 안전하게 통신 하는 방법에 동의해야합니다.
만약 협상에 실패하면, 오류 또는 경고를 표시합니다. 반대로 협상에 성공하면 URL 옆에 자물쇠가 생기며 브라우저에 웹 사이트가 표시됩니다. 브라우저와 서버간의 협상 프로세스를 "핸드 셰이크"라고 합니다.
1. AKA 클라이언트
AKA 단계에서는 SSL/TLS 버전과 암호화 알고리즘 목록을 서버에 전달합니다.
2. AKA 서버
서버는 브라우저가 보낸 것 중 가장 좋은 SSL/TLS 버전과 암호화 알고리즘을 선택합니다. 그리고 서버의 공개 키를 포함한 인증서를 보내 브라우저는 서버를 식별할 수 있습니다.
3. AKA 클라이언트 키 교환 & 4. AKA의 스펙 변경
브라우저는 서버의 인증서를 확인하고 'pre-master key'를 생성합니다. 해당 키는 나중에 클라이언트, 서버 양쪽 다 고유 키를 생성할 때 사용할 수 있습니다. 'pre-master key'를 서버의 공개 키로 암호화한 후 서버에 다시 전송합니다. 서버는 개인 키를 가지고 'pre-master key' 암호를 해독합니다.
5. AKA 모든 것의 확보
브라우저와 서버가 서로만 아는 공유비밀을 생성한 뒤 브라우저가 테스트를 보내고 서버가 응답을 보냅니다. 이제 브라우저와 서버 사이의 모든 데이터는 남은 세션 기간동안 보호 받습니다.
HTTPS, SSL 및 TLS의 차이점
HTTPS는 HTTP의 보안 버전입니다. HTTP는 브라우저 및 웹 서버가 서로 정보를 교환하고 소통하기 위해 사용하는 프로토콜입니다. 여기서 해당 데이터 교환이 SSL/TLS로 암호화 되면 이를 HTTPS라고 합니다.
1. SSL
SSL은 'Secure Sockets Layer'의 약어로, 넷스케이프에 의해 작성된 프로토콜입니다.
TLS는 'Transport Layer Security'로, 원래는 SSL 3.1버전이라 헷갈릴 수 있습니다.
요약하자면 SSL은 초기에 나온 프로토콜로 현재는 폐기된 프로토콜이지만, SSL에서 TLS로 넘어오는 과정에서 용어를 같이 사용하게 되었다.
인증 기관
인증기관(CA)는 3가지 목표를 가진 조직입니다.
- 인증서 발급
- 인증서 소유자의 신원 확인
- 인증서가 유효하다는 증거 제공
CA가 되기 위해서는 보안 요구 사항과 감사가 필요합니다. 왜냐하면 루트 저장소로 승인 되려면, 신뢰를 받아야 합니다. 루트 저장소는 기본적으로 신뢰할 수 있는 CA의 데이터베이스 입니다.
인증서 종류에는 3가지가 있습니다.
- 도메인 확인 인증서: 도메인 이름만 확인하고 다른 것은 확인하지 않습니다.
- 조직 확인 인증서: 인증서 뒤에 조직의 유효성 검증 및 수동 검증이 필요합니다.
- 확장된 검증 인증서: 사업에 대한 철저한 검증이 필요합니다.
인증서 유효성 검사는 '신뢰 체인'을 기반으로 합니다. 브라우저는 HTTPS를 통해 사이트에 연결하고 인증서를 다운로드 합니다. 이 과정에 체이닝으로 진행하면서 루트 인증서를 찾아 유효성을 검사합니다.
만약 마지막 인증서가 루트 인증서가 아니고 더 다운로드 할 인증서가 없다면, 해당 체인은 신뢰할 수 없는 체인으로 판별됩니다.
왜 인증서에 자체 서명을 할 때 인증기관을 사용할까?
정답은 자체 서명 인증서는 기관에서 생성한 것과 동일한 수준의 암호화를 제공하기 때문입니다.
하지만 자체 서명된 인증서는 테스트 및 인트라넷에서만 사용하고 공용 사이트에서는 사용하면 안됩니다. 왜냐하면 자체 서명된 인증서는 기본적으로 신뢰할만한 인증서이기 때문에 위조될 수 있기 때문입니다.