HTTPS

🐕 HTTPS

HTTPS란 HTTP Secure의 약자입니다.

HTTP에 Secure가 하나 더 붙었을 뿐이고.. Secure라는 단어에서 알 수 있듯이

HTTP 프로토콜을 좀 더 안전하게 사용할 수 있는 프로토콜이겠구나 라는 예상을 할 수 있습니다.

 

HTTPS가 HTTP프로토콜에 비해 안전한 이유는 HTTPS는

요청과 응답으로 오가는 내용을 암호화하기 때문입니다.

예컨대 HTTP로 보낸 요청은 패킷 분석 프로그램(ex : wireshark)을 이용하면

데이터의 내용을 그대로 확인할 수 있습니다. 따라서 비밀번호와 같은 민감정보들을

제 3자가 탈취할 수 있는 위험성이 생기게 됩니다.

그 위험성을 방지하기 위해 HTTPS는 대칭키 방식과 공개키 방식을 혼합한 암호화 방식을 사용합니다.

 

왜  HTTPS는 이 두가지 방식을 혼합하여 사용할까요?

그것을 알기 위해서는 위 두가지 방식의 장점과 단점을 알아야 합니다.

---

👻대칭키 암호화 방식과 공개키 (비대칭 키) 암호화 방식

대칭키 암호화 방식	공개 키 암호화 방식
하나의 키만 사용합니다.	두개의 키를 사용합니다.
암호화할 때 사용한 키로만 복호화가 가능합니다.	암호화할 때 사용한 키와 다른 키로만 복호화가 가능합니다.
연산 속도가 빠릅니다.	연산 속도가 상대적으로 느립니다.
키를 탈취당하면 암호화가 소용없어집니다.	공개키를 탈취 당해도 상관없습니다.

 

대칭키 암호화 방식

대칭키 암호화 방식은 하나의 키만 사용하며 암호화 할 때 사용한 키로만 복호화가 가능합니다.

두개의 키를 사용해야 하는 공개 키 방식에 비해서 연산 속도가 빠르다는 장점이 있으며

키를 주고받는 과정에서 탈취 당했을 경우에는 암호화가 소용없어지기 때문에

키를 관리하는 데에 신경을 많이 써야합니다.

 

공개 키 (비대칭 키) 암호화 방식

비대칭 키 암호화 방식은 두개의 키를 사용합니다. 암호화 할 때 사용한 키와 다른 키로만 복호화가 가능합니다.

여기서 두개의 키를 공개 키 , 비밀 키라고 부릅니다.

여기서 공개 키는 공개되어있기 때문에 누구든지 접근이 가능하며

누구든지 이 공개 키를 사용해서 암호화한 데이터를 보내면 비밀키를 가진 사람만

그 내용을 복호화 할 수 있습니다. 보통 요청을 보내는 사용자가 공개 키를

요청을 받는 서버가 비밀 키를 가집니다. 이 때 비밀 키는 서버가 해킹당하는 게 아닌 이상 탈취 되지 않습니다.

 

이러한 공개 키 방식은 공개 키를 사용해 암호화한 데이터가 탈취 당한다고 하더라도

비밀 키가 없다면 복호화할 수 없으므로 대칭 키 방식보다 보안성이 더 좋습니다.

하지만 대칭 키 방식보다 더 복잡한 연산이 필요하며 더 많은 시간을 소모한다는 단점이 있습니다.

 

aha 공개 키 방식은 빠르지만 보안에 문제가 있고

대칭 키 방식은 보안은 좋지만 비용이 많이 드는군요

---

🥶 SSL/ TLS 프로토콜

HTTPS 는 HTTP 통신을 하는 소켓 부분에서 SSL 혹은 TLS라는 프로토콜을 사용하여

서버 인증과 데이터 암호화를 진행합니다.

여기서 SSL 이 표준화 되며 바뀐 이름이 TLS이므로 사실상 같은 프로토콜로 생각할 수 있습니다.

 

이 SSL / TLS 는 다음과 같은 특징을 가집니다.

1. CA를 통한 인증서 사용
2. 대칭 키 , 공개 키 암호화 방식을 모두 사용

 

인증서와 CA(Certificate Authority)

HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있습니다.

이러한 인증서는 서버의 신원을 보증해줍니다.

이때 인증서를 발급해주는 공인된 기관들을 CA라고 부릅니다.

 

서버는 인증서를 발급받기 위해서 CA로 서버의 정보와 공개 키를 전달합니다.

CA는 서버의 공개 키와 정보를 CA의 비밀 키로 암호화하여 인증서를 발급합니다.

서버는 클라이언트에게 요청을 받으면 CA에게 발급받은 인증서를 보내줍니다.

이 때 사용자가 사용하는 브라우저는 CA들의 리스트와 공개 키를 내장하고 있습니다.

 

서버는 해당 인증서가 리스트에 있는 CA가 발급한 인증서인지 확인하고

리스트에 있는 CA라면 해당하는 CA의 공개 키를 사용해서 인증서의 복호화를 시도합니다.

CA의 비밀 키로 암호화된 데이터는 CA의 공개 키로만 복호화가 가능하므로

정말로 CA에서 발급한 인증서가 맞다면 복호화가 성공적으로 진행되어야 합니다.

 

복호화가 성공한다면 클라이언트는 서버의 정보와 공개 키를 얻게 됨과

동시에 서버가 신뢰할 수 있는 서버임을 알 수 있게 됩니다.

 

복호화가 실패한다면 서버가 보내준 인증서가 신뢰할 수 없는 인증서임을 확인하게 됩니다.

 

대칭키 전달

이제 사용자는 서버의 인증서롤 복호화하여 서버의 공개 키를 확보했습니다.

그럼 이 공개 키는 클라이언트와 서버가 함께 사용하게 될 대칭 키를 주고 받을 때 사용하게 됩니다.

대칭 키는 속도는 빠르지만 오고 가는 과정에서 탈취될 수 있다는 위험성이 있었습니다.

하지만 클라이언트가 서버로 대칭 키를 보낼 때 서버의 공개 키를 사용해서 암호화하여 보내준다면

서버의 비밀 키를 가지고 있는게 아닌 이상 해당 대칭 키를 복호화할 수 없을테니까

탈취될 위험성이 줄어들게 됩니다.

 

클라이언트는 데이터를 암호화하여 주고 받을 때 사용할 대칭 키를 생성합니다.

클라이언트는 생성한 대칭 키를 서버의 공개 키로 암호화하여 전달합니다.

서버는 전달받은 데이터를 비밀 키로 복호화하여 대칭키를 확봏바니다.

이작업까지 마치면 서버와 클라이언트는 동일한 대칭키를 갖게 됩니다.

 

이제 HTTPS 요청을 주고 받을 때 이 대칭키를 사용하여 데이터를 암호화하고 전달하면

대칭 키 자체는 오고가지 않으니까 키가 유출될 위험은 없어지고

따라서 요청이 중간에 탈취 되어도 복호화할 수 없게 됩니다.

 

HTTPS는 이러한 암호화 과정을 통해 HTTP보다 안전하게 요청과 응답을 주고받게됩니다.

정리하자면

 

SSL / TSL 프로토콜은

서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 담은 규약이고

HTTPS는

HTTP에 SSL/TLS 프로토콜을 더해준 것을 말합니다.

---

🐶마치며

HTTPS가 구성되는 방식이 흥미로운 것 같습니다.

다만... 살짝 헷갈리는 부분이 있어서 다시 한번 봐야할것같네요

---

이해했다고 생각할 때가 가장 무서울 때다.