HTTP와 HTTPS

HTTP (Hypertext Transfer Protocol)

서로 다른 시스템 사이에서 통신을 주고받게 하는 프로토콜로 80번 포트를 사용한다.

• 7계층의 application layer 및 TCP/IP 인터페이스의 application layer에 속한다.

서버에서 브라우저로 데이터를 전송하는 용도로 가장 많이 사용한다.

하지만 전송하는 정보가 암호화되지 않아 보안 관련 이슈가 존재할 수 있다.

• 중간에 패킷을 가로채는 등

• 쿠기가 제한될 수 있다.

HTTPS (Hypertext Transfer Protocol Secure)

HTTP에 SSL을 사용한 프로토콜이다.

SSL (보안 소켓 계층 = Secret Socket Layer) 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들게 도와주고 서버와 브라우저가 정보를 주고받을 때 해당 정보가 탈취되는 것을 막아준다.

HTTP 자체를 암호화하는 것이 아니라, HTTP의 Messege Body를 암호화한다.

• 여기서 Header는 암호화되지 않는다.

왜 HTTPS를 사용할까?

// HTTP
해커가 탈취 후 데이터 확인 : password1234

// HTTPS
해커가 탈취 후 데이터 확인 : $DDSDADD#$!#*

1. 보안성 확보

2. SEO, 검색 엔진 최적화 및 가속화 된 모바일 페이지(AMP)

   • 구글은 HTTPS를 사용하는 웹 사이트에 가산점을 부여한다. 자신의 웹 사이트가 더 노출되고 싶으면 HTTPS를 사용해야 한다.

   • AMP를 만들때도 HTTPS를 사용해야 함.

SSL/TLS (인증서 보장을 위한 노력)

TLS는 SSL의 업그레이드 버전이다. 하지만 둘 다 동일한 용어로 사용한다.

SSL 인증서를 무료로 발급해주는 서비스

• Let’s Encrypt

• AWS Certificate Manager

SSL (Secure Sockets Layer)

Netscape사에서 웹 서버와 웹 브라우저간 보안 강화를 위해 만든 프로토콜이다.

SSL은 공개키 + 개인키, 즉 공개키 방식과 대칭키 방식을 혼합해서 사용한다.

대칭키 방식 동일한 키(Key)를 가지고 암호화와 복호화를 수행하는 방법이다. → 암복호화에 사용하는 키가 동일 누구나 암호화에 사용한 키를 가지고 있다면 데이터를 쉽게 복호화할 수 있다. 대칭키 방식은 암/복호화가 쉽고 암호화 속도가 빠르며 대용량 데이터 암호화에 적합하다. 반대로 키를 교환해야 하기 때문에 키가 탈취되면 데이터가 쉽게 노출된다. 따라서 안전한 키교환 방식이 요구됨. 대표적인 알고리즘으로 AES, DES, SEED, ARIA가 있다. 공개키 방식

암복호화에 사용하는 키가 서로 다르며 비대칭키 방식(암호화)이라고 함. 암복호화키가 다른 암호화 방식을 사용하고, 데이터 암호화는 공개키를 사용, 복호화에는 개인키를 사용한다. 공개키로 암호화한 데이터는 오직 개인키로만 복호화할 수 있기 때문에 공개키는 노출되어도 상관없다. 단점은 대칭키 방식보다 암호화 연산시간이 오래걸려 비용이 더 발생한다. 대칭키 방식과 공개키 방식은 서로의 장점이 단점이 된다.

SSL에서는 각 방식이 가지는 단점으로 인해 한 방식만 채택하지 않고 두개를 적절히 섞어 사용한다.

SSL 통신 과정 (SSL Handshake, 인증 및 키 교환)

위 내용을 바탕으로, SSL은 공개키 방식으로 대칭키를 전달한다. 이 대칭키로 암복호화를 하고, 서버와 브라우저간 통신을 진행한다.

목적

• 클라이언트-서버가 주고받을 데이터의 암호화 알고리즘 결정

• 사용자가 접속한 사이트가 유효한지 어떻게 확인할까?를 통해 대칭키를 얻는 방법

1. Client → Server 연결을 시도하는 패킷을 전송한다.

   • 패킷 안에는 여기서 어떤 프로토콜(SSL/TSL)를 사용할지, 데이터를 어떻게 암호화할지 포함된다.

2. Server → Client 응답

   • 연결을 수락하고 지원하는 방법(암호화 등)을 선택하고 서버의 인증서, 공개키와 암호화 방법을 응답에 포함시켜 보낸다.

3. Server → Client

   • 2번 응답(패킷)외에 Certificate라는 패킷을 보낸다. 여기에는 Server의 SSL 인증서 내용이 있다.

   • 패킷 내부를 확인하면 인증서의 Signature algorithm, public key info 등 확인할 수 있다.

4. Client에서는 SSL 인증서를 검증

5. Client는 획득한 인증서의 공개키로 자신의 대칭키를 암호화해서 Server에 전달한다.

6. Client-Server SSL Handshake 종료

   • 서버는 클라이언트의 암호화된 대칭키를 자신의 개인키로 복호화하여 클라이언트의 대칭키를 획득하고 이것으로 통신할 준비를 끝낸다.

   • 통신할 준비가 되면 Server → Client로 Change Ciper Spec을 보낸다. 서버쪽도 SSL Handshake 준비 완료라는 의미의 패킷이다.

공개키 + 대칭키 방식을 혼합해서 사용하는 법

공개키 + 대칭키 혼합 사용 과정

1. 공개키 + 대칭키 혼합3A -> B로 접속 요청

1. B는 공개키-개인키를 생성하고 A에게 자신의 공개키를 전송한다.

1. A는 자신의 대칭키를 B의 공개키로 암호화한다.

1. A에서 암호화한 공개키를 B에게 전달한다.

1. B는 A의 대칭키를 자신의 개인키로 복호화한다.

   • B는 복호화의 결과로 A의 대칭키를 얻는데 성공한다.

   

2. 이렇게 획득한 대칭키를 가지고 서로 통신한다.

사용자가 접속한 사이트가 유효한지 어떻게 확인할까?

🌟사용자가 접속한 사이트가 유효한지 어떻게 확인할까?

1. 사이트는 사이트 인증서가 필요하다. 사이트 인증서는 인증 기관에서 사이트에게 발급해주는 문서이다.

사이트에서 인증기관에 사이트 정보와 사이트 공개키를 전달한다.

1. 인증기관은 사이트 인증서를 발급해주기 전, 전달받은 데이터를 검증한다.

인증 기관은 공개키-개인키 쌍을 생성한다. 검증을 완료하면 이 데이터를 인증기관의 개인키로 서명하고 사이트 인증서를 생성한다.

1. 검증이 끝나고 생성된 인증서를 사이트에 전달한다.

1. 인증기관은 사용자에게 공개키를 전달한다.

1. 전달받은 공개키는 사용자 브라우저에 자동으로 내장된다.

이 과정까지는 아직 사용자가 사이트에 접속하기 전 상황이다.

🌟사용자가 사이트 접속을 요청했을 경우

1. 사용자가 사이트에 접속 요청을 한다.

1. 사이트는 신뢰할 수 있는 사이트를 증명하기 위해서 인증서를 전달한다.

1. 사용자는 인증기관 공개키를 가지고 인증서를 복호화해서 검증한다.

복호화에 성공하면 사이트 정보와 사이트 공개키를 획득할 수 있다.

1. 획득한 사이트 공개키를 가지고 자신의 대칭키를 암호화한다.

1. 암호화된 사용자 대칭키를 사이트에 전달한다.

1. 사이트는 자신의 개인키로 사용자 대칭키를 복호화해서 사용자 대칭키를 획득한다.

1. 이제 이 대칭키로 서로 암호문을 주고받을 수 있다.

즉, SSL 통신이 시작된다.

TLS Handshake 주기

TLS 핸드쉐이크 과정에서 발생하는 세션 ID에는 유효기간이 설정되어 있고, 이 기간이 만료되면 다시 핸드쉐이크를 수행해야 한다. 그 외에도 세션을 재설정하거나 특정 설정을 변경할 경우 다시 TLS 핸드쉐이크가 수행된다.

참고 자료 : https://www.youtube.com/watch?v=wPdH7lJ8jf0