HTTP vs HTTPS

HTTP란?

- Hypertext Transfer Protocol의 줄임말로 서로 다른 시스템들 사이에서 통신을 주고받게 하는 가장 기본적인 프로토콜이다.

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

- HTTP는 80번 포트를 사용한다. 

- HTTP는 서버에서 브라우저로 전송되는 정보가 암호화되지 않는다는 문제점이 존재하여 데이터가 쉽게 도난당할 수 있다.

 

HTTP의 구조

HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers 등으로 구성된다.

https://mangkyu.tistory.com/98

정보가 암호화되지 않는다는 문제점이 존재하여 이 문제를 해결하기 위해 HTTPS가 등장하게 되었다.

 

HTTPS란?

Hyper Text Transfer Protocol Secure의 줄임말로 HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 볼 수 없도록 암호화를 지원합니다.

암호화는 공개키/개인키 대칭키 기반으로 사용합니다.

*공개키 : 누구든지 키를 확인할 수 있고 사용할 수 있도록 대중에게 공개된 키를 의미한다.

*개인키 : 자기자신만이 관리하고 가지고 있는 키를 의미한다.

 

대칭키 암호화

어떤 정보를 암호화, 복호화 할 때 사용하는 키가 동일(대칭)한 경우이다.

즉, 암호활 할 때 필요한 키 값과, 해당 정보를 복호화 할 때 필요한 키 값이 동일한 경우입니다.

어떠한 정보가 대칭키를 통해 암호화 되었다면, 똑같은 키를 갖고 있는 사용자가 아니면 해당 정보를 확인할 수 없습니다. 예를들어, A가 B에게 열쇠(키)와 상자를 보냈다고 생각하겠습니다. B는 열쇠와 상자 모두 전달 받았을 때 상자를 열어볼 수 있습니다. 하지만 중간에 다른 사람이 상자와 열쇠를 가로채면 그 사람도 상자를 열어볼 수 있게 됩니다. 따라서 열쇠와 상자를 안전하게 B에게 잘 전달되어야 하는게 핵심입니다.

정리하자면, 암호화 복호화가 매우 단순하지만, 키를 잘 전달해야한다는 문제점이 존재합니다.

 

비대칭키 암호화

어떤 정보를 암호화, 복호화 할 때 사용하는 키가 다른(비대칭)한 경우이다.

대칭키와는 다르게 비대칭키를 활용한 암호화에는 개인키와 공개키 두가지가 사용됩니다.

 

1) 공개키로 정보를 암호화한 경우

서로 다른 키로 암호화와 복호화를 수행합니다.

암호화는 모두가 알 수 있는 공개키로 복호화시에는 개인키를 사용합니다.

예를들어, A가 B에게 열쇠(공개키)와 상자를 보냈다고 생각하겠습니다. B는 상자를 받았지만 A가 보낸 열쇠(공개키)가 아닌 B의 열쇠(개인키)로 상자를 열 수 있는 것 입니다. 따라서 중간에 무장한 강도가 상자를 가로채더라도 열쇠(공개키)로 상자를 열 수 없기때문에 안전합니다.

 

2) 개인키로 정보를 암호화한 경우

암호화는 본인만 알고있는 개인키로 복호화시에는 모두가 알 수 있는 공개키로 할 수 있습니다.

예를들어, A가 B에게 열쇠(개인키)와 상자를 보냈다고 생각하겠습니다. B는 상자를 받고 A가 보낸 열쇠(개인키)가 아닌 모두가 알고있는 A의 공개키를 통해 상자를 열 수 있습니다. 만약 중간에 무장한 강도가 상자를 가로챈다면, A가 보낸 열쇠(개인키)가 아닌 A의 공개키로 상자를 열 수 있습니다.

그러면 우리는 중간에 누군가가 가로챌 수 있는 이러한 방식을 왜 사용할까요?

상자 안의 물건보다는 상자를 누가 보냈는지가 중요할 때 사용합니다.

 

즉, A의 상자는 A의 개인키로 암호화해야 보낼 수 있기 때문에 A의 공개키로 열리는 상자는 A만 전송할 수 있는 것입니다.

이러한 기술은 데이터 제공자의 신원이 보장되는 '전자서명'등 공인인증체계의 기본이 됩니다.

 

HTTPS의 동작 과정

서버 = 사이트, 클라이언트 = 사용자

1. 사이트(서버)는 공개키와 개인키를 만들어서 신뢰할 수 있는 인증기관에 자신의 정보와 공개키를 관리해달라고 계약합니다.

 

2. 이때, 계약을 완료한 인증 기관은 기관만의 공개키와 개인키가 있습니다. 인증기관은 사이트가 제출한 데이터를 검증하고, 인증 기관의 개인키로 사이트에서 제출한 정보를 암호화하여 인증서로 만들어 제공하고, 사이트는 인증서를 가지게 됩니다.

 

3. 인증기관은 웹 브라우저에게 자신의 공개키를 제공하게됩니다.

 

1. 사용자가 사이트에 접속하면 서버는 자신의 인증서를 웹 브라우저(클라이언트)에게 보냅니다.

예를들어, 웹 브라우저가 index.html 파일을 달라고 요청했다면, 서버의 정보를 인증 기관의 개인키로 암호화한 인증서를 받게 되는 것입니다.

2. 웹 브라우저는 위 인증기관 3번에서 미리 알고있던 인증기관의 공개키로 인증서를 해독하여 검증합니다. 그러면 사이트의 정보와 서버의 공개키를 알 수 있게 됩니다.

인증서는 인증기관의 비밀키로 암호화되어 있기 때문에 인증기관의 공개키로 복호화할 수 있습니다. 복호화 되지 않는다면 인증되지 않은 서버임을 알 수 있습니다.

3. 이렇게 얻은 서버의 공개키로 대칭키를 암호화하여 다시 사이트에 보냅니다.

4. 사이트는 개인키로 암호문을 해독하여 대칭키를 얻게 되고, 이제 대칭키로 데이터를 주고받을 수 있게 됩니다.

* 위 과정을 SSL handshake라고 함

HTTP와 HTTPS

HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있다. 하지만 HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느리다. (물론 오늘날에는 거의 차이를 못느낄 정도이다.) 또한 HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생합니다.

그렇다면 언제 HTTP를 쓰고, 언제 HTTPS를 쓰는 것이 좋을까요?

개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리하고 있다면 HTTP를 이용하면 된다.

 

 

출처

 

https://universitytomorrow.com/22

https://mangkyu.tistory.com/98

https://rachel-kwak.github.io/2021/03/08/HTTPS.html

https://junuuu.tistory.com/221?category=974977