[웹 개념] HTTPS와 HTTP의 차이점

1. HTTPS 등장 배경

 

인터넷의 등장과 함께 프라이버시 문제가 생겨났다.

인터넷을 기반으로 개인 맞춤형 서비스를 진행하다보니,

로그인을 통해 사이트에 고유한 개인 정보를 저장하게 되었고,

전자상거래를 통해 은행과 계좌와 관련된 비밀정보도 오가게 되었다. 

그러다 보니 중요한 개인정보가 유출되는 경우가 생기기 시작한다.

 

HTTPS는 HTTP가 전송하는 데이터가 암호화되지 않은 부분을 보완한 프로토콜이다.

TLS 계층을 거치는 방식으로 HTTP를 운영하여

HTTP의 전송 메시지 바디(전송되는 데이터가 있는 부분)를 암호화시키는 것이다.

 

 

 

 

2. HTTP와 HTTPS의 기본 개념과 차이점

 

HTTP는 클라이언트-서버 구조에 사용되는 프로토콜이다.

 

HTTP는 하이퍼 텍스트 전송 프로토콜의(Hypertext Transfer Protocol)의 약자이며,

서로 다른 시스템들 사이에서 통신을 주고받게 해주는 가장 기초적인 프로토콜이다.

 

HTTP의 단점은 "보안이 적용되지 않은 데이터"를 전송한다는 것이다.

이는 상당히 위험하다고 여겨지는데,

네트워크의 전형적인 공격인 "중간자 공격"에 취약하기 때문이다.

 

그렇기에 HTTP 자체는 보안에 상당히 취약한 프로토콜이라고 말할 수 있다.

 

 

 

 

HTTPS는 HTTP에 TLS 계층을 더한 것이다.

 

출처: https://blog.wishket.com/wp-content/uploads/2020/02/03-3.png

 

HTTPS는 하이퍼 텍스트 전송 프로토콜 보안(Hypertext Transfer Protocol Secure)의 약자이다.

위에서 언급했듯이 일반 HTTP 프로토콜의 문제점은

서버에서부터 브라우저로 전송되는 정보가 암호화되지 않는 것이었다.

 

HTTPS 프로토콜은 TLS(SSL(보안 소켓 계층)의 개선된 버전)을 사용함으로써 이 문제를 해결했다.

 

TLS은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고,

서버 브라우저가 민감한 정보를 주고받을 때 데이터가 도난당하는 것을 막아준다. 

 

 

이러한 암호화 메커니즘을 통해 암호학에서 핵심으로 두는 3가지 보안 기능성(CIA)을 얻게 된다. 

 

1. 기밀성(Confidentiality)

교환되는 데이터를 도청해도 의미가 없게끔 데이터가 강력한 암호 알고리즘으로 암호화된다.

대칭 알고리즘을 통해 암호화와 복호화된다.

 

2. 무결성(Integrity)

정보가 중간에 변질되지 않았음을 보장하는 것이다.

(중간에 중요한 정보만 가로채거나 수정하는 것을 방지)

클라이언트와 서버는 전자 서명(Digital Signature)을 통해 통신을 맺어 신뢰성을 확보한다.

 

3. 인증(Authentication)

응답자가 안전한 응답자인지 확인하기 위해 인증서 제도를 운영한다.

인증서 기관을 통해 해당 서버가 안전한 서버라는 것을 확인할 수 있다.

 

 

 

 

요약하면 HTTPS는 다음을 통해 보안성을 강화한다.

 

1. 클라이언트는 CA 인증서를 확인해서 안전한 서버임을 확인한다.
2. 클라이언트와 서버는 공개키/개인키(비대칭 암호화)를 통해서 안전한 통신 세션을 맺는다.
3. 공개키/개인키로 공유한 대칭키를 통해서 데이터를 암호화 복호화하여 데이터의 기밀성을 얻는다.

 

 

 

3. HTTPS의 암호화 전송을 이해하는데 필요한 개념들

출처: https://blog.eleven-labs.com/en/understanding-ssltls-part-1/

 

1. SSL과 TLS

 

SSL과 TLS는 둘 다 네트워크를 통해 작동하는 서버, 시스템 및 응용 프로그램 간에

"인증 및 데이터 암호화"를 제공하는 암호화 전용 프로토콜이다.

SSL은 TLS이전의 프로토콜로 2015년에 SSL 3.0은 지원이 중단되고 TLS가 사용되고 있다.

SSL 프로토콜이 남긴 레거시로 현재도 많은 분야에서 TLS와 SSL을 같은 표현으로 사용하기도 한다.

 

 

 

2. SSL/TLS 디지털 인증서 (CA를 통해 보장받음)

 

 

 

클라이언트와 서버 간의 통신을 공인된 제삼자(CA)가 보증해주는 문서이다.

해당 문서를 통해 서버의 안정성을 보장받을 수 있다.

(주소 입력창 HTTPS 프로토콜 쪽에 자물쇠로 확인 가능)

클라이언트로 하여금 접속하려고 하는 서버가 신뢰할 수 있는 서버인지 확인하는 데 사용한다. 

이 SSL/TLS 디지털 인증서가 적용되어야 구글 검색 엔진에서 가산점을 받을 수 있다.

 

 

 

3. 공통키 방식 VS 비대칭 키(공개키/대칭키) 방식

 

공통 키 방식: 암호화할 때와 복호화할 때 같은 키를 사용하는 방식

1. 장점: 단순한 구조로 CPU를 적게 쓰고 빠르다.
2. 단점: 공통 키를 빼앗기면 복호화를 할 수 있으므로 보안에 취약하다는 단점이 있다.
 

 

비대칭 키(공개키/대칭키) 방식: 암호화할 때와 복호화할 때 다른 키를 사용하는 비대칭 방식

1. 클라이언트는 공통 키를, 서버는 인증서와 공개 키를 제공하여,

   클라이언트는 서버가 제공한 공개 키를 통해 공통 키를 암호화하여 서버에게 전송한다.

   서버는 수신한 HTTPS의 인증서와 공개 키 일치를 바탕으로 공통 키를 복호화해 요청에 대응한다.
2. 장점: 키 전송과정 중 해킹 당해도 해커가 해독을 할 수 없으니 공통 키 방식보다 안전하다.
3. 단점: 공통 키 방식보다 느리고 리소스 소비가 크다.

 

 

 

 

4. 비대칭 암호화 과정

 

 

사전에 서로 다른 키를 공유하기 위해 사용하는 공개키 암호화

 

먼저 밥과 앨리스가 있다.

이 둘은 비밀 메세지를 주고받기 위해서 대칭키를 만들어야 한다.

공개키 암호화 방법을 이용해 대칭키를 만들어보자.

출처: https://koonsland.tistory.com/42

우선 밥과 앨리스는 각자 공개키와 개인키를 가지고 있다.

이때, 공개키는 오픈되어도 괜찮다.

따라서 밥과 앨리스는 자신의 공개키를 오픈되어 있는 공간에 올려놓는다.

이렇게 공개된 공개키는 아무나 가져갈 수 있다.

출처: https://koonsland.tistory.com/42

밥과 앨리스는 상대방의 공개키를 서로 가져온다.

그리고 밥은 앨리스에게 전달할 새로운 키를 하나 생성한다.

이렇게 생성한 키는 둘만 알고 있는 비밀키이며, 대칭키로 사용된다.

출처: https://koonsland.tistory.com/42

밥은 새롭게 생성한 대칭키를 앨리스의 공개키를 이용해서 암호화한다.

이렇게 암호화를 하게 되면, 오직 앨리스의 개인키를 이용해서만 이 암호문을 복호화할 수 있다.

따라서, 이 암호문을 다른 누군가가 탈취한다 해도 복호화할 수 없다.

 

그리고 이 암호화된 공개키를 앨리스에게 전달한다.

출처: https://koonsland.tistory.com/42

앨리스는 전달받은 암호화 키를 자신의 개인키로 복호화해서 원본 키를 갖게 된다.

그리고 밥이 했던 것과 마찬가지로,

앨리스는 밥의 공개키를 가져와서

새로운 대칭키를 생성하고 밥의 공개키를 이용해서 암호화한다.

 

이렇게 밥의 공개키로 암호화한 키를 밥에게 전달한다.

출처: https://koonsland.tistory.com/42

밥은 자신의 공개키로 암호화된 암호키를 개인키로 복호화하고 원본 키를 얻어낸다.

 

드디어 밥과 앨리스는 서로 공유된 대칭키를 이용해서 안전하게 메세지를 주고받을 수 있게 되었다.

이제 대칭키가 탈취되지 않는 이상 중간에서 메세지를 가져와도 원본 메세지를 알아낼 수 없다.

 

---

 

cf. 대칭키 대신 공개키로 메세지를 주고받는다면?

 

공개키와 개인키로도 암복호화가 가능하다.

따라서 공개키 암호화를 이용해서 메세지를 주고받을 수도 있다.

 

다만 공개키와 개인키는 키 길이가 굉장히 길기 때문에

암복호화하는 시간이 대칭키보다 오래 걸린다.

 

또한 원문(원래의 메세지)의 길이가 길어지면 길어질수록

암호화와 복호화의 시간이 점점 더 오래 걸리게 된다.

 

효율적인 면에서 떨어지기 때문에 보통은 대칭키를 공유하고

대칭키를 이용해서 메세지를 주고받는 것이 일반적이다.

 

 

 

cf. HTTPS는 공통키와 비대칭키를 함께 사용한다

1. 비대칭 키 방식이 가진 이점은 이어가되 전송 소요시간 및 리소스 부담은 줄이는 방식이다.
2. HTTPS를 통한 통신이 시작될 때, 

   서버는 서버가 제공한 공개 키와 증명서에 부합하는 요청을
   클라이언트가 보냈는지 확인한다.
   클라이언트가 공통 키를 서버가 제공한 공개 키로 암호화해

   서버에게 보낸 첫 번째 요청을 복호화하는 과정을 핸드쉐이크(handshake)라고 부르는데,
   이 과정이 끝나면 실제 요청과 정보를 교환하는 과정이 이어진다.
3. 서버가 제공하는 비대칭 키(=공개 키)를 써 클라이언트는 서버에게 보낼 공통 키를 암호화한다.
4. 서버는 클라이언트가 보낸 암호화된 요청을 비대칭 키로 복호화한다.
5. 결과적으로 클라이언트와 서버는 서버가 제공한 비대칭 키를 통해 암호화된 공통 키로 통신한다.

 

 

 

 

 

---

정리

 

HTTPS 방식 = HTTP + TLS(SSL)

 

1. 암호화: 어떤 정보를 암호화된 정보로 바꾸는 것
2. 복호화: 암호화된 정보를 다시 원래 정보로 바꾸는 것
3. 키: 암호화, 복호화할 때 쓰는 비밀번호
4. HTTPS는 공통 키 방식과 비대칭 키 방식을 같이 사용
 

 

 

 

 

 

 

 

 

 

 

 

---

자료 출처:

 

HTTPS와 HTTP의 차이점. 핵심은 SSL/TLS [ 네트워크 면접질문 6 ]

HTTP vs HTTPS 차이, 알면 사이트의 레벨이 보인다. - wishket

공개키 암호화! 원리와 사용방법을 알아보자!