[Network] HTTPS란?

Summary

https를 직접 프로젝트에 적용해본 경험을 가진 주니어들은 적을 것이라 생각한다. 하지만, http와 https의 차잇점은 웹 개발자의 기본소양이니 알아두도록 하자.

Http의 약점

• 암호화 하지 않은 통신이라 도청 가능 : http에는 암호화 기능이 없다.
• 통신 상대를 확인하지 않기 때문에 위장 가능
• 완전성을 증명할 수 없기 때문에 변조 가능 : 서버에서 보낸, 혹은 클라이언트에서 보낸 리소스와 요청한 곳에서 받은 리소스가 완전히 일치하는지 확인할 수 없음

이러한 약점을 극복하는 방법

SSL이나 TLS라는 다른 프로토콜을 조합하여 통신내용을 암호화 할 수 있다. SSL을 활용하여 안전한 통신로를 확보한 상태에서 통신하는 것을 Https(HTTP Secure)라 부른다.

콘텐츠를 암호화

콘텐츠 자체를 암호화 하는 방법도 있다. 메시지의 헤더는 암호화 되어 있지 않고, 메시지 바디에 들어있는 콘텐츠만 암호화 하여 브라우저와 웹서버에서 각각 복호화 하는 것이다.

SSL 증명서를 통해 통신상대를 확인

Http에서는 통신상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있다. SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서 를 제공하고 있다. 증명서는 신뢰할 수 있는 제3자 기관에 의해 발행되는 것이다.

통신내용의 완전성을 증명하는 방법

SSL은 요청과 응답의 변조를 막기위해 MD5, SHA-1 같은 해시값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법을 사용함

그래서 Https는?

SSL을 사용하면서 암호화와 증명서, 완전성 보호등을 이용할 수 있는 프로토콜

HTTP + 통신의 암호화(SSL) + 증명서 + 리소스의 완전성 보호 = HTTPS

Https란?

Https 는 새로운 애플리케이션 계층의 프로토콜은 아니다.

HTTP 통신을 하는 소켓 부분을 SSL(Secure Socket Layer)혹은 이것을 발전시킨 TLS(Transport Layer Security)이라는 프로토콜로 대체한 프로토콜. 보통의 HTTP는 직접 TCP와 통신하지만 SSL을 사용한 경우에는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다. SSL이 껍질의 역할을 하는 것이다.

공개키 암호화 방식

SSL에서는 공개키 암호화 방식이라 불리는 암호화 방식을 채용하고 있다.

현대의 암호는 알고리즘이 공개되어 있고 키를 비밀에 부침으로 안전성을 유지한다. 암호화나 복호화할 때 이 키를 사용하는데, 키가없으면 아무것도 못한다. 반대로 생각하면 키만 있으면 누구라도 암호를 풀 수 있다.

공통키(대칭키) 암호화

암호화와 복호화에 하나의 키를 사용하는 것을 공통키 암호화 방식이라 한다. 공통키(대칭키) 암호화 방식은 상대방에게 키를 넘겨주지 않으면 안된다. 하지만 어떻게 안전하게 상대에게 키를 넘겨줄 수 있을까? 넘겨주는 과정에서 키를 빼앗기면 암호화의 의미가 없어진다. 키를 안전하게 보낼 수 있다면 애초에 암호화에 의미는 없어진다.

공개키 암호화의 등장

공통키를 쓰게 되면 중간에 공통키를 무조건 전달해주어야 해서 중간에 탈취당할 위험이 있다. 그래서 키를 전달하지 않는 방법을 고안함.(암호문을 해독할 수 있는 키) 이 것이 공개키 암호화 방식

공개키 암호는 서로 다른 두 개의 키 페어를 사용한다. 한쪽은 비밀키, 한쪽은 공개키라 부른다.

- 비밀키 : 누구에게도 알려지면 안되는 키. 정보를 받아 들일 때 자신의 비밀키를 사용해 복호화한다.
- 공개키 : 암호를 보내는 측이 상대의 공개키를 사용해서 암호화함

공개키 암호를 사용한 통신방식을 사용하면, 각자의 공개키를 서로에게 보내고, 상대의 공개키로 암호화한 내용을 주고 받는다. 메시지를 받으면 각자의 비밀키로 의미를 해석한다.

만약 중간에 공개키와 암호문을 탈취당하더라도, 암호문과 공개키만으로는 평문을 구하는 게 굉장히 어렵다.(큰 수의 소인수 분해를 고속으로 할 수 있다면 가능하지만 현재로선 불가능)

공개키 암호화 방식의 단점

공개키 암호화 방식은 너무 복잡하기 때문에 암호를 해독하는 처리 속도가 늦다.

HTTPS는 하이브리드 암호 시스템

공개키 암호방식은 공통키 암호에 비해 처리속도가 늦다. 때문에 두 가지 장점을 모두 살릴 수 있도록 각각의 방식을 조합해서 통신한다.

키를 교환하는 곳에서는 공개키 암호를 사용하고 그 후의 통신에서 메시지를 교환하는 곳에서는 공통(대칭)키 암호를 사용한다.

1. 메세지를 주고 받을 상대에게 접속요청을 한다.
2. 상대방이 자신의 공개키를 준다.
3. 해당 공개키로 암호화할 때 사용할 공통(대칭)키를 암호화한다.
4. 상대방 공개키로 암호화한 나의 공통(대칭)키를 보낸다.
5. 서로 같은 공통(대칭)키를 갖고있기 때문에 다음 통신부터는 공통키로 암호화 한 내용을 주고 받는다.

증명서

만약, 공통(대칭)키를 암호화하는데 사용할 공개키가 악의적인 사용자에 의해 바뀐다면 어떻게 될까?

공개키가 진짜인지 아닌지 증명하기 위해, 인증기관(CA)과 그 기관이 발행하는 공개키 증명서가 이용되고 있다.

인증기관의 인증 방식

1. 사이트의 운영자가 인증기관에 '사이트 정보'와 '사이트의 공개키'를 제출
2. 인증 기관은 검증을 거쳐 '사이트 정보'와 '사이트의 공개키'를 '인증기관의 개인키'로 암호화한다(디지털 서명).
3. 디지털 서명이 끝난 '사이트의 공개키'와 '사이트 정보'를 '인증서'에 담는다.
4. 인증기관은 '인증서'를 검증을 요청한 사이트에 보내고, '인증기관의 공개키'는 웹 브라우저에 제공한다.
5. 사용자가 브라우저로 사이트에 접속하면 사이트는 자신의 '인증서'를 웹브라우저에 보낸다.
6. 브라우저는 갖고 있는 '인증기관의 공개키'로 암호화된 인증서의 내용을 복호화한다.
7. 인증이 끝나면 인증서에 있는 '사이트의 공개키'로 '사용자의 공통(대칭)키'를 암호화해서 보낸다.
8. 사이트는 자신의 개인키로 '사용자의 공통(대칭)키'를 복호화 해서 이것으로 암호문을 주고 받는다.

디지털 서명은 인증기관의 공개키로 복호화해서 공개키가 진짜인지 확인하면 된다.

인증기관의 공개키는 안전하게 클라이언트에 전달 되어야 한다, 때문에 인증기관의 공개키는 브라우저에 내장된 상태로 출시되고 있다.

사실 인증서에 가장 중요한 정보는 ‘사이트의 공개키’이다.

SSL은 느리다

HTTPS는 HTTP 보다 SSL 통신만큼 네트워크 리소스를 더 소비하여 통신시간이 더 걸린다. 또한 서버, 클라이언트 모두 암호화와 복호화 처리를 해야하기 때문에 CPU, 메모리 등 하드웨어 리소스를 더 사용한다.

근본적인 해결 방식은 없기에 SSL 엑셀레이터라는 하드웨어(어플리케이션 서버)를 사용해서 문제를 해결하기도 한다.

참고

• SSL 용어정리 및 공개키 개인키 그리고 인증서 원리와 통신방식
• 그림으로 배우는 Http & Network Basic

Sehun Kim

하다보니 되더라구요.