설탕빵의 설탕공방어제 이야기한거 => HTTP
오늘 이야기할꺼 => HTTPS
암호화 이야기할꺼니깐 다시 OSI 계층 들고오겠다.
어제 이야기: "L6는 데이터 표현 방식을 결정하는데 암호화 관련 내용이 있어서 나중에 보안쪽에서 다루고"
<출처: 숏텀 리눅스>
6번 보면 SSL/TLS이 보인다.
일단 평문으로 된 우리 데이터를 어떻게 암호화 되는가 알아보자.
암호화 하는 법
암호화 하면 아마 대칭키, 비대칭키 이야기 한번 들어봤을 것이다.
대칭 = 암호화랑 복호화랑 같은 키 사용
비대칭 = 서로 다른 키 사용
대칭키는 같은 키 쓰니깐 복잡하지 않아서 속도가 빠르다.
비대칭은 서로 다른 키를 쓰는데 각각 공개키, 개인키를 사용한다.
공개키는 말 그대로 모두에게 공개되지만, 이 키로 암호화한 데이터는 오직 짝이 되는 개인키로만 열 수 있다.
즉 공개되도 개인키가 있으니 "난 이걸로 암호화할꺼니 쓰고 싶음 써봐"가 되는거다.
그럼 우리 HTTPS의 전략은 무슨 키를 쓸까
정답은 두개 전부다.
비대칭키가 안전하긴 한데, 느리다는 단점이 있어서 용량 큰 웹페이지 데이터 전송하려면 빠른 암복호화가 필요하다.
그래서 빠르지만 키 공유가 어려운 대칭키를 비 대칭키로 암호화해서 전달하는 것이다.
배송 과정을 안전하게 하면 빠른 대칭키를 써도 되니깐
핸드세이크에 SSL/TLS 섞기
데이터를 어떻게 암호화 할 것인가 논의가 됬으면 이제 서로 주고 받고를 이야기해보자
통신전에 핸드세이크를 통해 서로 통신 파이프를 확립하면 실제 HTTP 요청 전에 먼저 정보 공유를 한다.
Cliient -> Server
"내 TLS 버전은 1.3이고 너가 쓸꺼 같은 암호화 방식으로 키 교환 재료 반쪽 만들어서 보냄"
Server -> Client
"너가 보낸거 받았는데 일단 내가 쓰는 암호화가 맞긴함, 나도 반쪽 재료로 니가 준거랑 합쳐서 세션키 만들었음 내 재로랑 인증서 같이 보냄. 난 준비됬음"
참고로 TLS 1.2 버전에서는 클라이언트가 암호화 목록 보내고, 쓸 수 있는거 허락받고 확인해서 키 교환했는데, 1.3은 효율성 따진다고 일단 보내고 맞음? ㅇㅇ 맞음 방식으로 통신을 진행한다.
틀리면 뭐 다시하고
아무튼 서로 재료 반쪽식 교환해서 같은 세션 키(대칭키) 공유한 시점부터 HTTP 요청과 응답은 빠른 대칭키로 암호화 되서 TCP 파이프를 통해 전송된다.
이게 HTTPS 다.
SSL 인증서랑 CA
아까 서버가 인증서를 보낸다는게 SSL 인증서다.
우리가 HTTPS 통신하려면 SSL 인증서가 필요하다는 것은 이미 알 것이다.
다만 SSL 인증서가 서버가 "나 구글이야"라고 하면서 주는건데, 어떻게 믿을 수 있느냐는 문제가 생긴다.
만약 해커가 중간에 우리 통신 가로채고 "내가 구글음"하고 자기 인증서 가져다 주면,
우리는 해커의 공개키로 데이터를 암호화하고, 해커는 자기 개인키로 내용을 다 까볼 수 있는거다.
그렇기 때문에 인증서를 인증해줄 또다른 제3의 기관이 등장하는데 그게 CA다.
인증서 검증 과정
구글 서버는 CA에 "www.google.com 내꺼임"하고 소유권을 주장하고 인증서 발급을 요청한다.
CA는 구글을 검증하고 "이 인증서는 www.google.com 소유가 맞음"이라는 내용을 자기 개인키로 서명해서 SSL 인증서를 발급한다..
클라이언트는 구글에 요청하면서 인증서를 받는다.
브라우저는 이제 받은 인증서 까면서 "이 인증서 CA가 보증함"이라는 것을 인식한다.
브라우저도 CA 공개키에 대해 내장되어 있어서 가진 CA 목록에서 알맞은 CA를 찾고 내장된 CA 공개키를 꺼낸다.
이 공개키로 복호화 되면? 진짜 CA, 안되면 가짜다.
이 과정을 통해 브라우저는 해커가 아닌 진짜 인증된 구글의 공개키를 안전하게 확보하고 통신이 가능한 것이다.
다음 챕터
이제 내용물을 암호화해서 보안을 챙기고
통신을 검증하는 과정에 있어서도 인증서를 통한 보안을 체크한다.
통신이 이루어졌으니 이제 실제로는 인프라의 영역이다.