HTTPS(Hyper Text Transfer Protocol Secure)
HTTPS 를 사용하는 이유
유저가 어떤 웹사이트에 보내는 정보를 다른 누군가 훔쳐보지 못하도록 하기 위함
ex)
HTTP로 만들어진 네이버에 로그인 시 아이디와 비밀번호를 네이버의 서버로 보낸다고 했을때
입력한 텍스트 그대로, 누구든 알아볼 수 있는 형식으로 보내집니다
만약 누군가가 이정보를 중간에 들여다 본다면 유저의 아이디와 비밀번호를 알게 되는거죠
HTTPS로 만들어진 네이버에 로그인 시 에는
유저의 아이디와 비밀번호를 네이버 서버의 인증서와 약속한 텍스트로 인코딩을 해서 보냅니다
다른 누군가가 로그인 정보를 중간에 들여다 보더라도 알아볼수가 없습니다.
HTTPS 의 동작원리
동작원리를 설명드리기 전에 먼저 사전지식이 필요해서 설명드리고 가겠습니다
대칭키
암호화/복호화 할 때 서로 키가 같은경우를 말합니다
-장점: 빠른연산
-단점: 키 노출시 암호화 무의미
비대칭키(공개키)
비대칭키 방식 또는 공개키방식이라고 불립니다
암호화할때와 복호화할 때 키가 서로 다른경우를 말합니다
초록색키로 암호화한 경우에 주황색키로만 복호화가 가능합니다
주황색키로 암호화한 경우에는 초록색키로만 복호화가 가능합니다
-장점: 공개키가 노출되더라도 개인키로만 복호화가 가능하므로 안전
-단점: 연산시간이 길어 서버의 성능에 영향을 줌
+)
HTTPS에서 대칭키를 사용할경우
클라이언트에는 암호화에 사용할 키를 가지고 있지 않기 때문에 한번은 서버에서 클라이언트로 암호화에 사용할 키를 전달을 해줘야합니다 서버에서 최초로 클라이언트에 암호화 키를 전달하는 그 시점에 암호화 키를 누군가 탈취한다면 암호화를 해서 통신을 하더라도 누군가도 암호화에 사용할 키를 가지고 있기 때문에 통신 중간에 들여다 볼수가 있게 됩니다
이를 보완한게 비대칭키 입니다
서버는 개인키/공개키 2개를 가지고 있습니다
클라이언트에서 요청시 공개키를 전달해줍니다
이 공개키로 암호화한 데이터는 서버가 가지고 있는 개인키로만 복호화가 가능하므로 안전합니다
비대칭키 방식은 서버의 성능에 영향을 주어 https에서는 대칭키/비대칭키 방식을 혼합하여 사용한다고 합니다
간략하게 설명드리면
클라이언트에서는 대칭키로 사용할 값을 공개키로 암호화해서 서버에 보내면 대칭키로 사용할 값을 개인키로 복호화 하면 이후에는 대칭키를 누군가에게 탈취당할 위험없이 사용이 가능하게 됩니다
TCP 3-way 핸드셰이크
핸드 셰이크는 악수를 의미하는데, 통신을 하는 브라우저와 웹 서버가 서로 암호화 통신을 시작할 수 있도록 신분을 확인하고, 필요한 정보를 클라이언트와 서버가 주거니 받거니 하는 과정이 악수와 비슷하여 붙여진 이름입니다
1) Client는 Server에게 접속요청을 위한 메시지(SYN)을 보냅니다. 이때 164728889같은 별 의미없는 난수를 SEQ넘버로 같이 실어서 보냅니다. 이제 Client는 SYN_SENT 상태가 됩니다.
2) Server는 Client에게 SYN요청을 받은 다음, 연결을 수락(ACK)합니다. 이를 합쳐서 SYN+ACK라고 표현하기도 합니다. 이때 클라이언트가 보내준 SEQ넘버에 딱 1을 더한 값과 서버측에서도 27319991같은 별 의미없는 난수를 ACK넘버로 또 보내줍니다. 이제 서버는 SYN_RECEIVED 상태가 됩니다.
3) Client는 Server에게 접속 수락 확인(SYN)을 보냅니다. 이때 서버측에서 넘겨준 ACK넘버에 또 1을 더해서 같이 보내줍니다. 이제 TCP연결이 성립되었으며, 서버는 ESTABLISHED 상태가 됩니다
[출처] TCP 3-Way Handshake 이해하기 [+실습/취약점 살펴보기]|작성자 루나뱅kQ
SSL 핸드 셰이크(handshake) 과정
① 클라이언트) 클라이언트가 먼저 서버에 접속해서 말을 겁니다.(Client Hello)
내가 브라우저 주소창에서 naver.com 입력하면 내 브라우저는 네이버 웹 서버에 접속 시도합니다. HTTP는 TCP의 일종이니, TCP 연결을 위한 3-Way Handshake를 수행한 브라우저는 네이버가 HTTPS를 사용하는 것을 알게 된 브라우저는 다음 정보를 Client Hello 단계에서 보냅니다.
- 브라우저가 사용하는 SSL 혹은 TLS 버전 정보
- 브라우저가 지원하는 암호화 방식 모음(cipher suite)
- 브라우저가 순간적으로 생성한 임의의 난수(숫자)
- 만약 이전에 SSL 핸드 셰이크가 완료된 상태라면, 그때 생성된 세션 아이디(Session ID)
- 기타 확장 정보(extension)
cipher suite 란, 보안의 궁극적 목표를 달성하기 위해 사용하는 방식을 패키지의 형태로 묶어놓은 것을 의미합니다. 여기서 보안의 목표란 다음과 같습니다.
- 안전한 키 교환
- 전달 대상 인증
- 암호화 알고리즘
- 메시지 무결성 확인 알고리즘
② 서버) 서버 또한 위의 인사에 응답하면서, 다음 정보를 클라이언트에 제공합니다.(Sever Hello)
- 브라우저의 암호화 방식 정보 중에서, 서버가 지원하고 선택한 암호화 방식(cipher sutie)
- 서버의 공개키가 담긴 SSL 인증서. 인증서는 CA의 비밀키로 암호화되어 발급된 상태입니다.
- 서버가 순간적으로 생성한 임의의 난수(숫자)
- 클라이언트 인증서 요청(선택 사항)
③ 클라이언트) 브라우저는 서버의 SSL 인증서가 믿을만한지 확인합니다.
대부분 브라우저에는 공신력 있는 CA들의 정보와 CA가 만든 공개키가 이미 설치되어 있습니다. 서버가 보낸 SSL 인증서가 정말 CA가 만든 것인지를 확인하기 위해 내장된 CA 공개키로 암호화된 인증서를 복호화해봅니다. 정상적으로 복호화가 되었다면 CA가 발급한 것이 증명되는 셈입니다. 만약 등록된 CA가 아니거나, 등록된 CA가 만든 인증서처럼 꾸몄다면 이 과정에서 발각이 되며 브라우저 경고를 보냅니다.
④ 클라이언트) 브라우저는 자신이 생성한 난수와 서버의 난수를 사용하여 premaster secret을 만듭니다.
웹 서버 인증서에 딸려온 웹 사이트의 공개키로 이것을 암호화하여 서버로 전송합니다. 서버 인증서에 공개키가 같이 딸려오는 부분이 이해가 어려우신 분들은 아래 디지털 인증서의 원리에 대한 글을 한번 보세요.
⑤ 서버) 서버는 사이트의 비밀키로, 브라우저가 보낸 premaster secret 값을 복호화합니다.
복호화 한 값을 master secret 값으로 저장합니다. 이것을 사용하여 방금 브라우저와 만들어진 연결에 고유한 값을 부여하기 위한 session key를 생성합니다. 세션 키는 대칭키 암호화에 사용할 키입니다. 이것으로 브라우저와 서버 사이에 주고받는 데이터를 암호화하고 복호화합니다.
⑥ 서버/클라이언트) SSL handshake를 종료하고, 드디어 HTTPS 통신을 시작합니다.
브라우저와 서버는 SSL handshake가 정상적으로 완료되었고, 이제는 웹상에서 데이터를 세션 카를 사용하여 암호화/복호화하며 HTTPS 프로토콜을 통해 주고받을 수 있습니다. HTTPS 통신이 완료되는 시점에서 서로에게 공유된 세션 카를 폐기합니다. 만약 세션이 여전히 유지되고 있다면 브라우저는 SSL handshake 요청이 아닌 세션 ID만 서버에게 알려주면 됩니다. 이 부분은 ①에서 언급되었습니다.
Googling 해보시면 SSL 핸드 셰이크 과정에 대한 내용이 글마다 조금씩 다릅니다. 구현체마다 다양한 옵션을 가지고 있어서 그런 것인데, 원리는 같은 것이니 크게 신경 쓰지 않으셔도 됩니다.
위에 이론?은 한두번 읽어보면 어지럽습니다
클라이언트가 서버에 접속 요청을 함
서버는 공개키와 개인키를 가지고 있다가 공개키를 클라이언트에 전달
클라이언트는 공개키를 받아 자신만의 대칭키를 공개키로 암호화해서 서버에 전달
공개키로 암호화한 클라이언트의 대칭키를 서버에서 개인키로 복호화
이때 외부(해커)로부터 안전한 대칭키를 클라이언트와 서버가 가지게 됨
안전하게 공개키 방식으로 통신이 가능함
위처럼 HTTPS는 대칭키/비대칭키 방식을 효율적으로 사용합니다
클라이언트가 접속한 서버의 인증서가 유효한지 확인은 어떻게 하는지?
먼저 서버는 SSL인증서가 필요하기 때문에 인증기관으로부터 인증서를 발급받기 위해
서버의 공개키와 서버정보를 전달합니다
인증기관에서는 전달받은 데이터를 인증기관의 개인키로 서명을 합니다
서명한 이 정보가 서버의 인증서가 됩니다
서버는 인증기관으로부터 전달받은 인증서를 서버에 저장 해둡니다
+)인증기관들은 브라우저에 인증기관의 공개키를 제공합니다
클라이언트가 서버에 접속을 하기전 브라우저는 이미 주요인증기관의 리스트/공개키를 보유하고 있습니다
클라이언트가 서버에 접속요청시 서버는 서버의 인증서를 클라이언트에게 전달하고
클라이언트에서는 전달받은 인증서를 보유하고 있던
인증기관의 공개키로 복호화해서 검증을 합니다
이 이후부터 위에서 설명드렸던 SSL핸드셰이크를 하고 통신을 합니다
HTTPS를 적용하면 100% 안전한가
HTTPS는 웹에서 보안을 적용하기 위한 가장 기본적인 단계이고, 이것으로 모든 보안성이 완벽하게 지켜졌다고 할 수 없습니다. 예를 들면, 웹 서버가 해커의 다양한 공격에 의해 루트 권한을 탈취당했다면 모든 기밀 데이터를 열람할 수 있는 권한이 넘어갈 수도 있습니다. 또한 HTTPS는 전달 구간에 대한 보안 기술인데, 전달 구간 중간에 해커가 중간자 공격(Man in the middle attack)을 수행할 수 있는 취약점이 있다면 HTTPS는 유지되지만 전달하는 내용은 고스란히 노출되기 때문입니다.
참고자료
https://blog.naver.com/agerio100/221948546623
https://www.youtube.com/watch?v=H6lpFRpyl14
https://www.youtube.com/watch?v=kBlQiwXSx8A
https://www.youtube.com/watch?v=wPdH7lJ8jf0
https://brunch.co.kr/@sangjinkang/38
