[Network] HTTP와 HTTPS

HTTP

HTTP = HyperText Transfer Procol

• OSI 7계층중 7계층 응용계층에 속하는 프로토콜이다.
• Stateless 한 특성을 갖는 프로토콜이다.
• Method, Path, Version, Header, Body 등으로 구성된다.
• Request와 Response로 통신을 하는 비연결성 프로토콜이다.

단점

• 평문 텍스트, 즉 암호화되지 않은 텍스트를 전송하는 프로토콜로, 중간자 공격에 취약하다.
• 변조, 위장, 도청에 취약하다.

HTTPS

HTTPS = HyperText Transfer Protocol over Secure Socket Layer = HTTP over SSL = HTTP over TLS

쉽게 말해서 HTTP의 단점인 보안성을 보완한 프로토콜이다.

데이터 암호화 기능이 추가되었다고 생각하면 된다.

HTTPS는 SSL 이라는 프로토콜을 사용하여 데이터를 암호화한다.

SSL 이란?

SSL은 공개키 암호화를 기반으로 동작하는 프로토콜이다.

대칭키와 공개키

암호학에서 사용되는 키는 크게 대칭키와 공개키로 구분할 수 있다.

대칭키 : 암호화/복호화에 사용되는 키가 동일한 방식. A와 B가 암호통신을 하려 한다면 A와 B는 공통된 대칭키를 가지고 있어야 한다.

공개키 : 대칭키와 다르게 키를 공개키와 비밀키 두 가지로 나눈 방식. 여기서 공개키는 말 그대로 공개된 키로 다른 사용자들에게 공개된다. 하지만 비밀키는 오직 비밀키의 소유자만이 알고 있는 키이다. 공개키로 암호화된 평문은 비밀키로 복호화가 가능하고, 비밀키로 암호화된 평문은 공개키로 복호화가 가능하다.

그렇다면 공개 키 방식으로 암호화를 한다면 어떤 효과를 얻을 수 있을까?

---

암호화로 얻을 수 있는 효과

가령, A와 B가 암호화 통신을 하려고 한다고 하자.
A는 B의 공개키를 알고 있고, B는 A의 공개키를 알고 있다.

 

A -> B : B's공개키암호화(Text)
: A는 B의 공개키를 알고 있기 때문에 B의 공개키로 Text를 암호화하면 B는 본인의 비밀키로 복호화할 수 있다.

 

A -> C : B's공개키암호화(Text)
: A가 B의 공개키로 암호화한 Text를 C에게 전송한다면, C는 B의 비밀키를 모르므로 복호화할 수 없다.

 

즉, 공개키로 암호화하는 것은 해당 공개키의 소유자만이 해당 암호문을 복호화 할 수 있음을 의미한다.

---

A -> B : A's비밀키암호화(Text)
: A가 본인의 비밀키로 Text를 암호화한다면 B는 A의 공개키로 복호화할 수 있다.

 

A -> C: A's비밀키암호화(Text)
: A가 본인의 비밀키로 Text를 암호화한다면 C 역시 A의 공개키로 복호화할 수 있다.

 

즉, 비밀키로 암호화하는 것은 해당 암호문은 A에 의해 생성된 것이라는 일종의 인증의 기능 을 갖는다.

---

SSL 사용 목적

1. 통신내용이 공격자에게 노출되는 것을 막을 수 있다.
2. 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 판단할 수 있다.
3. 통신내용의 악의적인 변경을 방지할 수 있다.

즉, SSL은 위와 같은 목적을 위해 인증서 를 사용한다.

이 인증서는 믿을만한 공인된 기관에서 발급해준다. 그러한 기관을 CA (=Certificate Authority)라고 한다.

믿을만한 기관인 CA에게서 인증서를 발급받은 서버는 클라이언트 입장에서 믿고 사용할 수 있다.

SSL은 이러한 인증서를 통해 클라이언트와 서버가 보안적으로 안전한 상태로 통신하게 돕는다.

인증서와 SSL의 동작 과정

이 인증서에는 아래와 같은 내용이 담겨있다.

• 서비스 서버의 정보 (인증서를 발급한 CA, 서비스 서버의 도메인)
• 서비스 서버 측 공개 키 (공개 키 값, 공개 키 암호화 방법)

그리고 브라우저는 CA의 리스트와 그 공개 키들을 가지고 있다.

SSL의 동작 과정 중 일부를 간략하게 설명해보자면,

1. 클라이언트가 서버에 접속/요청한다. (handshake + 랜덤 데이터를 보낸다)

2. 서버는 클라이언트에게 CA의 비밀키로 암호화된 인증서를 제공한다. (handshake + 랜덤 데이터를 보낸다)

// 이 랜덤 데이터는 앞으로 통신에서 사용할 세션 키를 생성하는 과정 중 하나이다.

3. 클라이언트는 본인이 가지고 있는 CA 리스트와 인증서에 담긴 CA 정보를 비교한다.

4. 일치한다면 해당 CA의 공개키로 인증서를 복호화한다.
    - 인증서가 CA가 암호화한 것임을 알 수 있음 (= 신뢰 가능)

이렇게 신뢰할 만한 서버임을 보장받은 상태에서 클라이언트는 서로 받은 랜덤 데이터를 조합하여 premaster secret 키를 생성한다.

이 때 인증서에 담겨있던 서비스 서버 측 공개키를 사용하여 암호화한다.

이렇게 암호화된 premaster secret 키를 서버에게 전송한다.

그렇다면 현재 서버와 클라이언트 모두 premaster secret 즉 대칭키로 사용 가능한 키를 갖게 된다.

이 premaster secret을 일련의 과정을 거쳐 session key로 만든 후 향후 있을 서버/클라이언트 간 통신에 사용하게 되는 것이다.

Session key

이 session key는 공개키 와 대칭키 가 결합된 방식이다.

굳이 왜 결합해서 쓸까?

공개키 방식은 많은 컴퓨팅 자원을 요구한다. 시간이 많이 걸린다는 것이다.

따라서 대칭키를 공개키 방식으로 암호화한 세션 키를 사용하면 더 안전하고 빠른 통신을 할 수 있기 때문이다.

인증서

> 크롬 브라우저에서 주소창 왼쪽에 보면 자물쇠가 보일 것이다.

 

 

 

 

 

> HTTPS를 사용 중인 곳이라면 이런 식으로 https를 사용 중이다 라는 문구가 보인다. 인증서 탭을 클릭해보자.

 

 

 

 

> 위에서 언급했듯이 서버의 공개키가 담겨 있는 모습을 확인할 수 있다.