HTTP, HTTPS

HTTP

HTTP는 Hyper Text Transfer Protocol로서 클라이언트(웹 브라우저)와 서버가 데이터를 주고받기 위한 통신 규약을 의미한다.

HTTP는 단어 그대로 텍스트를 클라이언트와 서버 간 교환하기 때문에 몇 가지 문제가 발생한다.

• 서버에 보내는 정보가 노출되어 중간에서 제 3자가 탈취할 수 있다.
  • 아이디, 비밀번호와 같이 민감한 정보를 보내는 경우 제 3자가 해당 데이터를 탈취한다면 문제가 발생한다.
  • 제 3자가 데이터를 탈취할 수 있다면 변조 또한 가능하다.

• 요청한 사이트가 믿을 만한 사이트인지 진위여부를 판단할 수 없다.

 

HTTPS

HTTP + Secure가 HTTPS이다. 즉 HTTP에서 발생하는 보안 이슈들을 보완해서 안전하게 서버와 데이터를 주고받을 수 있다.

• 서버에 보내는 데이터를 암호화해서 전송한다.
  • 암호화된 데이터는 제 3자가 중간에 탈취하더라도 해당 데이터의 복호화 키가 없기 때문에 확인하거나 변조하는 것이 불가능하다.
• 인증된 기관을 통해 해당 사이트의 인증서의 진위 여부를 판단하기 때문에 요청한 사이트가 신뢰할 수 있는 사이트임을 판단할 수 있다.

이렇게 Http와 달리 가장 크게 보안적인 이슈를 강화할 수 있는 이유는 CA (Certificate Authority)라고 불리는 인증된 기업이 중간에 있기 때문이다.

CA는 복잡한 절차를 모두 통과하고 인증된 민간 기업으로 브라우저는 이 CA의 목록이 내장되어 있다.

 

HTTPS의 요청 흐름

애플리케이션 서버가 HTTPS를 적용하고 클라이언트가 서버와 데이터를 주고받는 단계를 알아보자.

먼저 애플리케이션 서버의 공개키를 인증서로 발급 받는 과정을 확인하자.

1. HTTPS를 적용하고자하는 애플리케이션 서버는 개인키와 공개키를 생성한다.
2. CA는 자신의 개인키와 공개키를 가지고 있다.
3. 애플리케이션 서버는 인증된 CA와의 계약을 통해 서버의 공개키와 CA의 이름 등 정보를 CA의 개인키로 암호화한 인증서를 발급받는다.

 

다음으로, 클라이언트는 서버와의 데이터를 주고받는 과정을 확인하자.

1. 클라이언트는 데이터를 주고받고자 하느는 애플리케이션 서버 URL로 접속을 요청한다. 이 때 클라이언트는 랜덤한 데이터 A를 함께 보낸다.
2. 서버는 클라이언트에게 CA에서 발급받은 공개키가 담긴 인증서와 랜덤한 데이터 B를 새로 생성해서 보낸다.
3. 클라이언트의 브라우저에는 이미 CA의 목록들이 저장되어있기 때문에 응답 받은 인증서와 알맞은 CA의 공개키를 가지고 복호화를 진행한다.
4. 인증서가 성공적으로 복호화가 되었다면 클라이언트는 서버의 공개키를 획득할 수 있다.
5. 클라이언트는 자신이 생성해 서버에 보낸 랜덤 데이터 A와 서버가 생성한 랜덤 데이터 B를 이용해 대칭키를 생성하고 인증서를 복호화해 얻은 서버의 공개키로 해당 대칭키를 암호화해서 서버에 전달한다.
6. 서버는 자신의 개인키를 이용해 대칭키를 복호화해서 획득한다.
7. 클라이언트와 서버 둘만 아는 대칭키를 획득 했기 때문에 대칭키를 이용해 데이터를 암호화한 상태로 서로 주고 받는다.

 

 

HTTPS가 HTTP에 비해 보안적으로 강화되었기 때문에 안전한 것은 맞으나, 신뢰할 수 있는 CA 기업이 인증한 인증서가 아니거나 개인이 자체적으로 발급한 인증서인 경우 보안적인 이슈가 발생할 수도 있다.

이러한 경우 HTTPS로 URL 요청이 이루어지지만 ‘주의 요함’, ‘안전하지 않음'과 같은 알림을 전달해준다.

출처 : https://durichat.tistory.com/65

 

📄 References

Gyoogle :  https://github.com/gyoogle/tech-interview-for-developer/blob/master/ComputerScience/Network/HTTP %26 HTTPS.md

HTTP vs. HTTPS (HTTP와 HTTPS 차이점) : https://hyeran-story.tistory.com/159