암호화 & 복호화하는 키가 동일하다면 → 대칭 키 암호화 방식
암호화 & 복호화하는 키가 다르다면 → 공개 키(비대칭 키) 암호화 방식
→ 일반적으로 요청을 보내는 사용자가 공개 키를, 요청을 받는 서버가 비밀 키를 가진다.
💡 장, 단점- HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다.
- 이러한 인증서는 서버의 신원을 보증해주는데 -> 이때 인증서를 발급해주는 공인된 기관들을 CA(Certificate Authority라고 부른다.
- 서버는 클라이언트에게 요청을 받으면 -- CA에게 발급된 인증서를 --> 클라이언트에게 전달한다.
! 이때, 사용자가 사용하는 브라우저는 CA들의 리스트와 공개 키를 내장하고 있는 상태이다.
- 클라이언트는 전달받은 해당 인증서가 리스트에 있는 CA가 발급한 인증서인지 확인하고,
- 리스트에 있는 CA라면 해당하는 CA의 공개 키를 사용해 인증서의 복호화를 시도한다.
- CA의 비밀 키로 암호화된 데이터(인증서)는 CA의 공개 키로만 복호화가 가능하므로 -> 정말 CA가 발급한 인증서가 맞다면 복호화가 성공적으로 진행되어
=> 클라이언트는 서버의 정보와 서버의 공개 키를 얻게 되고, 동시에 해당 서버의 신뢰성이 입증된다.
1. 클라이언트는 얻은 서버의 **공개 키**를 통해 -- **대칭 키**를 만들어 --> 서버에게 전달한다.
- 대칭키는 속도는 빠르지만 오고 가는 과정에서 탈취될 수 있는 위험성이 있다.
- 하지만 클라이언트가 서버로 대칭 키를 보낼 때, 서버의 공개 키로 암호화하여 보낸다.
-> 서버의 비밀 키를 가지지 않는 이상 해당 대칭키를 복호화할 수 없으므로(공개 키로 암호화하면 -> 비공개 키로 복호화해야한다)
-> 탈취 위험이 줄어든다.
2. 서버는 전달받은 데이터를 비밀키로 복호화 해 대칭 키를 확보한다.
- 이렇게 서버와 클라이언트는 동일한 대칭키를 갖게 된다.
3. 이제 HTTPS 요청을 주고 받을 때 이 대칭 키를 사용해 데이터를 암호화 해 전달한다.
- 대칭 키 자체는 오가지 않아 키가 유출될 위험이 없다 --> 따라서 중간에 데이터가 탈취되어도 제 3자가 암호화된 데이터를 복호화할 수 없다.
=> HTTPS는 이러한 암호화 과정을 통해 더욱 안전한 요청과 응답을 주고 받을 수 있게 해준다.
이렇게 서버와 클라이언트간의 CA를 통해 서버를 입증하는 과정과 데이터를 암호화하는 과정**을 아우른 프로토콜을
=> SSL 또는 TLS 라고 말하고,
=> HTTP에서 + SSL / TLS 프로토콜 => HTTPS