HTTPS 란?

HTTPS는 HTTP의 보안 취약점을 개선한 프로토콜이다.

일반적인 HTTP 통신 방식에서 SSL/TSL이 추가된 개념이다.

SSL/TSL은 통신하는 데이터를 암호화하기 위한 프로토콜이다.

무슨 소리인지 하나도 모르겠다. 천천히 글을 따라서 읽어보면 완벽하게 이해할 수 있을 것이다.

HTTP의 보안 취약점

HTTP가 어떤 보안적으로 취약했을까.

크게 세가지를 말할 수 있다.

암호화하지 않은(평문) 통신

암호화되지 않은 데이터를 주고 받기 때문에, 누군가 통신 중간에서 데이터를 가로챈다면 너무 위험했다.

아래 그림에서 위처럼 암호화되지 않은 비밀번호를 가로챈다면, 바로 내 비밀번호가 들키게 되고, 마음이 너무 아플 것이다.

하지만 암호화를 거쳐 통신하게 되면, 뺏겨도 안심이다! 어차피 암호화된 데이터를 읽는 것은 거의 불가능하기 때문이다.

이런 의문이 든다.

"그럼 HTTP 통신에서도 보낼때부터 암호화해서 보내면 되잖아."

물론 가능하다. 하지만 생각해보자.

어떤 데이터를 암호화하고 그 데이터를 읽으려면 다시 복호화 과정이 필요하다.

클라이언트에서 암호화한 데이터를 서버로 보내고, 서버에서 그 데이터를 복호화하기 위해선 서로 약속된 암호화할 키, 복호화할 키를 미리 알고 있어야한다.

결국, 암호화키, 복호화키도 안전하지 않은 HTTP 통신을 이용해서 한번은 서로 공유해야한다는 것이다.

이 과정 또한 너무 위험하다. 매번 암호화되지 않은 데이터를 보낼때보단 낫겠지만, 암호화키 복호화키가 절대적으로 안전하다고 할 수 없다.

HTTPS는 이 과정을 어떻게 해결했는지 아래에서 확인하겠다.

누구와 통신 중인지 증명할 수 없다.

HTTP 통신 과정에선, 요청한 측과 응답한 측이 누구인지 증명할 수 없다.

예시로, 내가 요청 헤더에 매번 "나 진짜 클라이언트야. 믿어봐"를 담아서 보내더라도 어떤 나쁜 사람이 그 요청을 가로채서 본 뒤에, 똑같이 "재 가짜야, 내가 사실 진짜 클라이언트야." 이러고 보내면 서버는 매우 혼란스러울 것이다.

마구 버린 손톱을 먹은 쥐가 사람으로 둔갑해서 혼란을 야기한 동화를 생각해보자.

누가 사람인지 HTTP 방식으로 판단했다면, 쥐를 선택했을 수도 있다.

하지만 HTTPS 방식으로 판단했다면, 아무리 감쪽같이 둔갑해도 사람만 선택할 수 있다.

HTTPS가 도대체 뭐길래 이걸 해낸 것인지 아래서 살펴보자.

암호화 방식

HTTPS에 대해서 알아보기 전에 두가지 암호화 개념이 필요하다.

• 대칭키 방식
• 비대칭키 방식

뭐 이렇게 알아야하는게 많나.. 싶겠지만 사실 별거 없는 내용이니 겁먹지 말자.

대칭키 방식

위 그림처럼 하나의 키만으로도 암호화/복호화가 가능한 방식이다.

암호화와 복호화에 동일한(대칭) 키를 사용하는 것이다.

대칭키를 사용한 이야기를 들려주겠다.

전쟁중에 적국에서 활동중인 우리 요원한테 대칭키 방식으로 암호화된 편지를 해독할 수 있는 키를 보내야한다.

비둘기 발에 키를 묶어서 보내는 도중에, 비둘기를 적국에서 가로채버렸다.

이제 그 키를 통해서 모든 편지 내용을 다 해독할 수 있게 되었다.

이처럼, 대칭키 방식에서는 키를 안전하게 공유하는게 가장 핵심이다.

비대칭키 방식

위 그림처럼 비대칭키 방식은 암호화할 때랑 복호화할 때랑 다른(비대칭) 키가 필요하다.

여기선 공개키와 개인키라는 개념이 들어간다.

공개키는 말 그대로 공개되어 있는 키다. 누구든지 접근할 수 있다.

개인키는 말 그대로 개인키다. 개인적으로만 가지고 있다.

다음 규칙만 딱 기억하면 된다.

1. 공개키로 암호화한 것은 개인키로만 복호화가 가능하다
2. 개인키로 암호화한 것은 공개키로만 복호화가 가능하다

너무 쉽다.

위에서 예시로 든 이야기를 다시 써먹어보자.

이때, 공개키는 어차피 누구나 다 알아서 적국도 다 알고 있다. 즉, 들켜도 상관 없는 것이다.

1. 비둘기에 요원의 공개키로 암호화한 편지를 실어서 날리는 경우

적국이 비둘기를 가로채도, 요원의 개인키가 없으므로 해독할 수 없다.

요원만 그 편지를 읽을 수 있는 것이다.

2. 비둘기에 내 개인키로 암호화한 편지를 실어서 날리는 경우

적국이 비둘기를 가로챘을 때, 내 공개된 키로 해독이 가능하다.

즉, 요원과 적국 모두 해독이 가능하다.

"? 뭐야 그럼 위험한거 아냐?"

맞다. 그래서 이 방식은 중요한 데이터를 보내는 것에 초점이 맞춰진 방식이 아니다.

내가 보낸 편지라는 걸 증명할 때 쓰인다.

내 공개키로 편지가 해독됐다는 것은, 내가 보낸 편지라는게 증명되는 셈인 것이다.

다시 한번 정리해보자.

1. 대칭키 방식

서로 같은 키를 가지고 있지만 하면, 빠르게 해독 및 암호화 가능

2. 비대칭키 방식에서 A의 공개키로 암호화한 경우

A만 읽을 수 있다는 것이 보장되는 방식. 앞으로 비대칭키 방식1이라고 부르겠다.

3. 비대칭키 방식에서 A의 개인키로 암호화한 경우

A가 보낸 것이 보장되는 방식. 앞으로 비대칭키 방식2이라고 부르겠다.

HTTPS는 위 3가지 방식을 모두 사용하고 있다.

정확히 어떻게 구현된 것인지 확인해보자.

HTTPS

비대칭키 방식은 암호/해독 과정에 많은 컴퓨터 리소스가 든다는 것을 기억해두자.

따라서, 매번 비대칭키 방식으로만 통신하면 컴퓨터가 파업할 수도 있다. 

이 때문에, 대칭키랑 비대칭키 방식을 적절히 섞어서 사용한다. 

어떻게 적절히 사용하는지는 아래를 읽어보면 된다.

HTTPS 통신에서 서로간의 신뢰를 보장하기 위해서 CA라는 개념이 추가된다.

공개키들은 저장하고 관리해주는 신뢰있는 기업이라고 생각하면된다.

나같은 사람이 하고 싶다고 CA를 할 수 있는 것은 아니고, 신뢰있는 사람만 운영할 수 있다.
(사실 할 수는 있는데, 나를 CA로 두면 크롬에서 못미더운 곳이라고 경고 문구를 띄운다.)

HTTPS를 이해하기 위한 모든 용어를 알았으니, 순차적으로 어떻게 이루어지는지 살펴보면서 설명하겠다.

내가 서버를 만들고, 그 서버에 누군가가 요청을 보내는 것까지의 시나리오다.

---

나 : "간지나게 HTTPS로 올려야지, 그럼 일단 공개키랑 개인키부터 만들어야겠다"

(다 만든 후)

나 : "내 서버는 안전한 곳이라고 증명해야되니까 신뢰있는 CA를 이용해서 공개키를 뿌리자."

(CA한테 찾아감)

나 : "내가 만원 줄테니까 내꺼 공개키좀 관리해줘."

CA : "오키. 내 이름하고 너 공개키 넣어서 내 개인키로 암호화했어"

?? 뭔 소리야 싶다면 아래를 읽어보자.

{
    CA 기업: "신뢰있는 기업 이름"
    요청한 서버 공개키: "12312313213"
} 
를 CA의 개인키로 암호화했다는 뜻이다. 

즉, CA가 껴있다는 것이 인증된 셈이다. -> 비대칭키 방식2

이 암호화된 정보들을 인증서라고 부른다.

나 : "인증서 잘 받았어. 잘 쓸게"

(클라이언트에서 요청이 옴)

클라이언트: "너랑 통신좀 하고 싶은데"

나 : "자 여기 인증서 줄게. 이걸로 내 공개키 얻어봐"

중요 : 브라우저는 신뢰있는 CA의 공개키를 모두 미리 알고 있다.

(브라우저가 CA 이름을 대조해가며, 일치하는 CA 공개키로 인증서 해독)

(해독 완료 후 서버의 공개키 얻게됨)

클라이언트: "오 해독이 되네. 진짜 그 서버에서 온 인증서라는 것도 확인됐다. 비대칭키 방식은 힘드니까 앞으로 쓸 대칭키를 서버의 공개키로 암호화해서 보내야지."

여기가 중요하다.

• CA의 공개키로 해독이 진짜 됐다는 것은 인증서가 진짜 CA에서 인증한 인증서라는 것을 입증한 것이다. -> 비대칭키 방식2 사용

• 인증서를 보내준 서버 또한 CA에서 인증한 신뢰된 서버라는 것도 알게된 셈이다.

비대칭키를 사용하는 것은 위에서 말한대로 리소스 소모가 심하다.

• 앞으로의 통신에 대칭키 방식을 이용하기 위해 앞으로 통신에 사용될 대칭키를 서버의 공개키로 암호화하는 것이다. -> 비대칭키 방식1 사용

이후의 데이터 통신은 모두 대칭키 방식으로 이루어진다.

정리를 해보자면,

• HTTPS에서 첫 연결 시에만 비대칭키 방식으로 대칭키를 교환한다.
• 대칭키를 교환한 후에는 대칭키 방식으로 암호화/복호화하며 통신한다.

즉 비둘기에 대칭키를 달아서 보내는 것은 위험하니, 대칭키 자체를 비대칭키 방식으로 암호화해서 비둘기에 암호화된 비대칭키를 보내버린 것이다.

이런 방식으로 이제 우리는 진짜 사람이 누구인지, 쥐가 누구인지 알 수 있다.

서버는 인증서를 통해 자기를 인증할 수 있고,
클라이언트는 서버의 공개키를 가지고 있음으로 자기를 증명할 수 있다.