HTTP [Hyper Text Transfer Protocol]
HTTP(Hyper Text Transfer Protocol)란 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 응용계층 프로토콜이다. 즉, 인터넷 하이퍼텍스트를 교환하기 위한 통신 규약으로 80번 포트를 사용하고 있다.
HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이였기 때문에, HTTP는 제3자가 정보를 조회할 수 있다. 이러한 문제를 해결하기 위해 HTTPS가 등장하게 되었다.
HTTP의 구조
HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.
HTTPS [Hyper Text Transfer Protocol Secure]
HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원하고 있다.
대칭키와 비대칭키 암호화
대칭키 암호화
어떤 정보를 암호화 및 복호화를 할 때 사용하는 키가 동일(대칭)한 경우이다.
즉, 암호화 할때 필요한 키값과, 해당 정보를 복호하 할 때 필요한 키값이 동일한 경우이다. 어떠한 정보가 대칭키를 통해 암호화 되었다면, 똑같은 키를 갖고 있는 사용자가 아니면 해당 정보를 확인할 수 없다.
클라이언트에서 로그인할 때 실어보내는 비밀번호를 대칭키로 암호화하고 비밀번호를 받는 서버는 대칭키로 복호화해서 인식할 수 있는 것이다.
암호화가 되어있기 때문에 중간에 제 3자가 정보를 훔쳐보더라도 알아볼 수 없을 것이다.
🔥 대칭키의 한계점
애초에 대칭키를 어떻게 양쪽이 공유한다는 것이 한 가지 의문점이다.
결국 한 번은 한 쪽에서 다른 한 쪽으로 대칭키를 전송해야 하는데 중간에 제 3자가 훔쳐보게된다면 의미가 없기 때문이다. 이것이 대칭키의 한계점인 것이다
비대칭키 암호화
대칭키의 한계점을 보안하기 위해 1970년대에 수학자들에 의해 개발된 방식이 비대칭키 방식이다. 비대칭키 암호화 방식에는 두 개의 키가 사용된다. 각각의 키를 A키와 B키라고 예를 들어 설명하자면 각 키는 서로 다르기 때문에 "비대칭키"라고 부른다.
대칭키 암호화에서는 어떤 키로 암호화를 하면 같은 키로 복호화를 할 수 있었지만 비대칭키 방식에서는 A키로 암호화를 하면 B키로만 복호화를 할 수 있습니다. 반대로 B키로 암호화를 하면 A키로만 복호화를 할 수 있는 것이다.
개인키 : 나만 가지고 알고 있어야 하는 키
공개키 : 나머지 하나의 키는 모두에게 공개하는 키
클라이언트가 공개키로 비밀번호를 암호화해서 서버측으로 보낸다고 가정했을 때
제 3자가 비밀번호를 가로채더라도 같은 공개키로는 클라이언트가 보낸 암호문을 풀어낼 수 없게 되는 것이다.
암호화 되어있는 것을 볼 수 있는 것은 개인키를 가지고있는 서버뿐인 것이다.
이러한 원리로 개인 정보들을 안심하고 서버측으로 보내게 되는 것이다.
하지만 클라이언트가 사용하고있는 웹사이트가 올바른 웹사이트인지 증명해야한다는 점이 남아있다. 특정 웹사이트에서 클라이언트에게 보내는 정보들은 그 일부가 해당 웹사이트 서버의 개인키로 암호화 되어있다. 클라이언트에서 데이터를 공개키로 암호화하여 서버에게 전달할 때 서버는 개인키로 그것을 복호화하여 알아볼 수 있듯이 서버에서 개인키로 암호화한 정보들을 특정 서버의 공개키로 복호화하여 볼 수 있게 되는 것으로 올바른 웹사이트인지 증명할 수 있게 되는 것이다.
신뢰할 수 있는 기관에서 클라이언트에게 특정 웹사이트의 공개키임을 검증해준다면 사용자는 안전하게 웹사이트를 이용할 수 있게된다.
여기서 신뢰할 수 있는 공인된 민간기업들을 CA(Certificate Authority)라고 한다.
🔥 정리
클라이언트/서버 관계에서 서버는 개인키를 가지고 있으며 클라이언트의 공개키로 암호화 되어있는 정보들을 개인키를 이용하여 복호화하고 클라이언트는 공개키를 이용해 서버에게 데이터를 받기 위해 개인키로 암호화 되어있는 데이터를 공개키를 이용해 복호화할 수 있다. ⇒ 신뢰할 수 있는 기관 CA(Certificate Authority)에서 공개키 검증
HTTPS의 동작 과정
웹사이트를 HTTPS에서 실행하려면 SSL(Security Sockets Layer) 인증서가 필요하다. Netscape에서 개발한 이 SSL인증서는 웹 사이트의 데이터를 암호화하고 웹 사이트 방문자에게 당신의 웹 사이트가 안전하다는 것을 증명하는 역할을 한다.
클라이언트는 서버를 신뢰하지 못해 탐색과정을 거치게 된다. 이 과정을 HandShake 라고 부른다.
🔥 Hand-Shaking 과정
- 클라이언트는 랜덤한 데이터(세션키)를 서버에게 보낸다.
- 서버는 클라이언트이 세션키를 받은 답변으로 서버측에서 생성한 무작위 데이터(세션키)와 인증서(공개키)를 보낸다.
후에 연결 과정(Hand-Shaking)에서의 무작위 데이터들을 통해 서버와 클라이언트 간에 세션키를 만들어 교환하고 여기서 세션키는 주고 받는 데이터를 암호화하기 위해 대칭키로 사용된다.
Hand-Shaking 이후 클라이언트는 인증서 검증을 위해 브라우저에 내장된 CA(Certificate Authority)들의 정보를 통해 확인한다.
=> 비대칭키 암호화 방식 사용
🔥 비대칭키 암호화 방식 사용 과정
- CA(Certificate Authority)의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화 되어있다. 알맞은 개인키라면 브라우저에 저장된 CA(Certificate Authority)의 공개키로 인증서를 복호화한다.
- 공개키로 복호화될 수 있는 인증서를 발급할 수 있는 이유 : 공개키에 대응하는 개인키를 가진 것은 CA(Certificate Authority)뿐이기 때문이다.
- 성공적으로 복호화된 인증서에는 서버의 공개키가 포함되어 있다.
복호화된 인증서에서 받은 공개키로 데이터들을 암호화해서 비대칭키 방식으로 주고받으면 되는 것은 아닌 데이터들을 대칭키 방식과 비대칭키 방식이 혼합되어 주고받게 된다.
- Why❓
웹사이트를 이용할 때 주고받는 다량의 데이터를 비대칭키로 암호화 및 복호화 하는 과정은 컴퓨터에게 부담이 많이가기 때문이다.
그러므로 데이터는 대칭키로 암호화하며 대칭키를 공유할 때 비대칭키를 사용한다.
클라이언트와 서버는 세션키를 대칭키로 공유하며 공유시 대칭키(여기서는 세션키와 같음)를 비대칭키 방식으로 공유한다.
앞서 언급했듯이 클라이언트는 Hand-Shaking 1,2과정에서 생성된 무작위 데이터 둘을 혼합하여 임시키(세션키)를 만든다. 이 키는 서버의 공개키로 암호화돼서 서버로 보내진 후 동일한 대칭키가 만들어진다. 이 대칭키는 서버와 클라이언트 둘만 가지고 이으므로 이후 서로 주고 받아질 데이터들을 제 3자에 대하여 보호받는 것이다.
즉, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것이다.
🔥 HTTPS의 동작 과정 총 정리
- client는 server에 대해 신뢰를 할 수 없으므로 일련의 탐색 과정인 hand-shaking을 거치게 된다.
- client와 server의 hand-shaking 과정을 통해 client는 server에게 SSL인증서을 받는다.
- client는 server에게 받은 SSL인증서가 올바른 인증서인지 확인하기 위해 인증된 민간기업 CA를 통해 판별한다.
- CA의 개인키로 암호화 되어있는 SSL인증서는 그에 대응하는 CA의 공개키로 복호화 할 수 있다 CA의 공개키는 해당 브라우저의 정보에 포함되어 있다. (비대칭키 방식)
- CA의 공개키로 SSL인증서를 복호화 했다면 클라이언트가 접속한 해당 server의 공개키를 발급받게 되는 것이다. (올바르지 않은 공개키일 경우 에러가 발생하게 되는 것이다.)
- client와 server의 hand-shaking 과정에서 생성된 세션키를 server의 공개키로 암호화하여 client가 server에게 전달한다. (비대칭키 방식)
- 전달된 세션키를 통해 대칭키를 만들어 데이터 전달에 사용된다. (대칭키 방식)
참고 자료
https://mangkyu.tistory.com/98
https://www.ascentkorea.com/difference-between-http-and-https/
https://universitytomorrow.com/22
https://www.youtube.com/watch?v=H6lpFRpyl14
