암호와 인증을 곁들인 HTTPS: 안전한 통신을 위한 핵심 요소

HTTP와 HTTPS는 애플리케이션 계층의 프로토콜로 브라우저와 웹 서버 간의 통신을 관리한다. 대부분은 HTTPS 통신을 하지만 HTTP로 통신하는 웹 사이트에 접속하면 아래와 같은 경고문을 볼 수 있다.

HTTPS로 연결하지 않아 안전하지 않다고 한다. 왜 HTTP는 안전하지 않을까?

HTTP(Hyper Text Transfer Protocol)

브라우저와 웹 서버 간의 통신을 위한 프로토콜이다. 텍스트로 정보를 주고받는데, 평문 그대로 전송하기 때문에 보안 문제가 발생할 수 있다.

👉 평문과 암호문
평문은 암호화하지 않은 정보로, 암호키로 평문을 암호화하면 암호문이 된다.

HTTPS(Hyper Text Transfer Protocol Secure)

HTTP 기반에 SSL(TLS)을 추가하여 보안을 강화한 버전이다. HTTP는 평문 그대로 전달하지만 HTTPS는 암호문으로 전달하기 때문에 보안상 유리하다.

SSL은 트랜스포트 계층의 프로토콜로 두 가지 과정으로 HTTPS 통신이 가능하도록 한다.

• 하이브리드 방식의 암호화로 대칭키를 안전하게 전달

• 디지털 서명으로 공개키의 신뢰성 확보

하이브리드 방식의 암호화

암호키를 이용한 암호화 방식은 크게 두 가지가 있다.

대칭키 암호화

암호화와 복호화에 동일한 키를 사용하는 방식으로 처리 부하가 작은 장점이 있다.

하나의 키로 암호화와 복호화 모두 가능하기 때문에 외부에 노출하지 않고 공유해야 하는 어려움이 있다.

공개키 암호화

한 쌍의 암호키를 생성한 후, 각각의 키로 암호화와 복호화를 하는 방식이다. 보통 외부에 공개하는 키를 공개키라고 하며, 나머지 하나를 비밀키라고 한다. 공개키로 암호화한 암호문은 같은 쌍의 비밀키로만 복호화 할 수 있으며, 반대의 경우도 가능하다.

공개키로 암호화할 경우, 비밀키로만 복호화가 가능하기 때문에 공개키가 노출되어도 큰 문제가 없다. 다만 서로 다른 키로 암호화, 복호화 하기 때문에 처리 부하가 크다는 단점이 있다.

하이브리드 방식은 두 가지 방식을 조합해서 대칭키를 안전하게 전달한다. 미리 전달한 공개키로 대칭키를 암호화한 후, 전달하기 때문에 대칭키를 외부에 노출시키지 않고 키를 공유할 수 있게 된다.

디지털 서명

하이브리드 방식의 암호화로 대칭키를 안전하게 전달할 수 있었다.

그런데 그 공개키... 믿을 수 있을까?

공개키로 암호화한 정보는 같은 쌍의 비밀키로만 복호화 할 수 있다고 했다. 만약 누군가 악의적으로 흘린 공개키로 대칭키를 암호화하면 대칭키가 그 누군가에게 노출된다. 따라서 공개키를 사용하기 전에 공개키의 신뢰성을 확보해야 하는데, 이를 위해 사용하는 것이 디지털 서명이다.

디지털 인증서

디지털 서명은 HTTPS 통신을 위한 인증서를 발급하는 과정에서 생성된다. 인증서는 CA에서 발급하며, 기업은 서버 공개키가 포함된 기업 정보를 전달하고 인증서 발급을 요청한다.

CA(Certificate Authority)
공신력 있는 제3의 기관으로 인증서를 발급하고 관리한다.

인증서 발급 과정

인증서 발급 요청을 받은 CA는 다음 과정을 거쳐 암호화된 인증서를 발급한다.

1. CA는 서버 공개키를 포함한 기업 정보를 전달받는다.

2. 기업 정보를 해시값으로 변환하고 CA 비밀키로 해시값을 암호화한다. 이렇게 암호화된 해시가 디지털 서명으로 사용된다.

3. 기업 정보와 디지털 서명을 포함한 인증서를 만들고 CA 비밀키로 암호화한다.

4. 암호화된 인증서를 요청한 기업에게 발급한다.

암호화된 인증서는 브라우저로 전달되며, 디지털 서명으로 공개키의 신뢰성을 확보할 수 있다.

공개키의 신뢰성이 확보되는 과정

브라우저가 암호화된 인증서를 받으면, 미리 가지고 있던 CA 공캐키로 복호화한다.

CA 공개키로 디지털 서명을 복호화하고 인증서에 있는 기업 정보를 해시값으로 변환한 후, 두 값이 동일한지 확인한다. 두 값이 동일하다면 공개키가 변조되지 않았음을 알 수 있다.

여기서 송신자의 신뢰성도 확보된다.

보통 공개키는 암호화를 위해 사용되지만 반대도 가능하다고 했다. 공개키가 암호화가 아닌 복호화로 사용된다는 것은 해당 암호문이 같은 쌍의 비밀키에 의해 암호화됐다는 것을 의미한다. 따라서 해당 암호문을 보낸 송신자가 비밀키를 가지고 있는 CA라는 것이 특정된다.

이 과정으로 송신자와 서버 공개키의 신뢰성이 확보된다.

브라우저와 웹 서버의 HTTPS 통신

브라우저와 웹 서버가 HTTPS 통신을 준비하는 과정을 살펴보자.

먼저 브라우저가 서버로 요청을 보내면 서버는 응답과 함께 암호화된 인증서를 전달한다.

브라우저는 미리 가지고 있던 CA 공개키로 암호화된 인증서를 복호화하고 서버 공개키를 확보한다. 그리고 디지털 서명으로 해시값을 비교해 해당 공개키가 진짜인지 확인한다. 서버 공개키의 신뢰성이 확보되면, 대칭키를 생성하고 서버 공개키로 암호화한다. 암호화된 대칭키는 서버로 전달되고 서버의 비밀키로 복호화된다.

이렇게 클라이언트와 서버가 안전하게 대칭키를 보유할 수 있게 된다. 이후부터는 대칭키로 통신하고 통신이 끝나면 대칭키는 폐기된다.

인증부터 통신까지!!

인증서 발급부터 시작해서 각 과정에 대해 알아보았다. 이제까지의 과정을 하나로 통합해 HTTPS 통신의 전체 흐름을 파악해 보자.

1. HTTPS 통신을 위해 기업은 CA에 서버 공개키를 포함한 기업 정보를 전달하고 인증서 발급을 신청한다.

2. CA는 기업 정보와 디지털 서명으로 인증서를 만들고 CA 비밀키로 암호화한 후 신청한 기업으로 전달한다.

3. 브라우저에서 서버로 요청을 보내면 서버는 응답과 함께 암호화된 인증서를 전달한다.

4. 브라우저는 CA 공개키로 암호화된 인증서를 복호한다.

5. 인증서에 있는 기업 정보를 해시값으로 변환하고, CA 공개키로 디지털 서명을 복호화한 값과 동일한지 확인한다.

6. 두 해시값이 동일하면, 대칭키를 생성하고 서버 공개키로 암호화한 후 서버로 전달한다.

7. 서버는 자신의 비밀키로 암호화된 대칭키를 복호화한다.

8. 클라이언트와 서버가 같은 대칭키를 보유하게 되었고, 통신이 끝나면 대칭키를 폐기한다.

정리

HTTPS가 어떻게 보안을 강화하는지, 그 과정이 어떻게 흘러가는지 알아보았다. 통신과정에 적용된 개념들을 다시 한번 정리해 보자.

• HTTP는 평문 그대로 통신하기 때문에 보안에 취약하다. 반면, HTTPS는 SSL(TLS)을 사용해 보안을 강화한 버전으로 암호문으로 통신하기 때문에 보안상 유리하다.

• SSL은 하이브리드 암호화 방식과 디지털 서명을 사용해 HTTPS 통신이 가능하도록 한다.

  • 디지털 서명은 공개키의 신뢰성을 확보하기 위한 것으로 기업 정보를 해시값으로 변환해 CA 비밀키로 암호화한 것이다.

  • 하이브리드 암호화 방식은 공개키 암호화 방식과 대칭키 암호화 방식을 조합한 방식으로, 대칭키를 공개키로 암호화해서 안전하게 전달한다.

• HTTPS 통신을 하려면 CA로부터 인증서를 발급받아야 하며, 인증서에 포함된 서버 공개키를 사용해서 대칭키를 안전하게 전달할 수 있게 된다.

• 브라우저와 서버는 대칭키로 통신하며, 통신이 끝나면 사용한 대칭키를 폐기한다.

참고

https://devdy.tistory.com/14

https://gyoogle.dev/blog/computer-science/network/대칭키&공개키

https://gyoogle.dev/blog/computer-science/network/HTTP%20&%20HTTPS.html

https://gyoogle.dev/blog/computer-science/network/TLS%20HandShake.html

그림으로 배우는 네트워크 Network 원리(Gene, 2020, Ch7)