공부정리

[네트워크] SSL과 HTTPS

에드박 2022. 1. 5. 03:08

HTTP의 약점

HTTP는 다음과 같은 약점들이 있다.

  • 암호화 하지 않은 평문 통신이기 때문에 도청이 가능하다.
  • 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
  • 완전성을 증명할 수 없기 때문에 변조 가능

이 약점은 HTTP만이 아닌, 다른 암호화하지 않은 프로토콜에도 공통되는 문제이다.

그럼 위의 3 가지 항목들이 왜 약점이 되는지 하나씩 살펴보자

암호화 하지 않은 평문 통신이기 때문에 도청이 가능

HTTP를 사용한 Request나 Response 통신 내용은 HTTP 자신을 암호화하는 기능은 없다. 때문에 통신 전체가 암호화 되지 않는다.

 

즉, 암호화되지 않은 평문 통신으로 HTTP 메세지를 보내게 된다.

 

어째서 암호화되어 있지 않은 통신에 약점이 있냐 하면 TCP/IP는 도청 가능한 네트워크이기 때문이다. 

TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있기 때문이다. 이말은 악의를 가진 누군가가 엿볼 수 있다는 것을 의미한다.

 

모든 곳에서 도청이 가능하다

 

통신 내용을 엿볼 수 있다는 것은 암호화된 통신, 암호화되지 않은 통신 모두 해당한다.

차이점이라면 암호화된 통신은 엿보더라도 복호화가 필요하다는 점이다.

 

같은 세그먼트의 통신을 도청하는 것은 어려운 일이 아니다. 네트워크 상을 흐르고 있는 패킷을 수집하는 것만으로 도청할 수 있게 된다.

(패킷 수집에는 패킷을 해석하는 패킷 캡처(대표적으로 WireShark 가 있다)나 스니퍼 라는 툴을 사용한다.)

 

WireShark 의 사용화면 Http 요청의 내용을 확인할 수 있다. (이미지 출처 : https://hsm-racoon.tistory.com/24)

 

암호화로 도청을 피하기

1. 통신 암호화

HTTP에는 암호화 구조는 없지만 SSL(Secure Socker Layer)이나 TLS(Transport Layer Security)이라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다.

 

SSL 등을 이용해 안전한 통신로를 확립하고(TCP) 나서 그 통신로를 사용해 HTTP 통신을 한다. SSL을 조합한 HTTP를 HTTPS(HTTP Secure)나 HTTP over SSL이라 불리고 있다. (보통 HTTPS 라고 부른다.)

 

2. 콘텐츠 암호화

통신하고 있는 콘텐츠의 내용 자체를 암호화해 버리는 방법.

HTTP에 암호화를 하는 기능은 없기 때문에 HTTPS를 사용해서 운반하는 내용을 암호화하는 것.

즉, HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것이다.

 

이 경우, 클라이언트에서 HTTP 메시지를 암호화해서 출력하는 처리기가 필요하다. 또한 암호화를 유효하게 하기 위해 클라이언트와 서버가 콘텐츠를 복호화할 수 있는 구조를 가지고 있어야하는 것이 전제가 되야한다. 따라서 평상시 브라우저와 웹 서버에서 이용하는 것은 어렵다. (주로 웹 서비스 등에서 이용되는 방법)

통신 상대를 확인하지 않기 때문에 위장 가능

HTTP 요청이나 응답에서는 통신상대를 확인하지 않는다.

즉, 클라이언트가 보낸 요청이 기대한 서버에 도착할지 모른다는 것. 요청을 보냈는데 그 너머에는 다른 서버가 해당 요청을 받을 수도 있다.

서버 또한 응답을 받은 대상이 요청을 보냈던 클라이언트인지 알 수 없다.

 

이는 HTTP에 의한 통신에서 상대가 누구인지 확인하는 처리가 없기 때문이다.

  • 서버는 요청이 오면 상대가 누구든 무언가의 응답을 내어 준다.(IP주소나 포트 등에서 액세스 제한이 없다면)
  • 요청을 보낸 곳의 웹 서버가 원래 기대한 서버인지 아닌지 확인할 수 없다. (위장한 웹 서버일 우려가 있다.)
  • 응답을 받은 클라이언트가 요청을 했던 클라이언트인지 알수 없다.(위장한 클라이언트 일 수 있다.)
  • 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다.
  • 어디의 누가 요청을 보냈는지 확인할 수 없다.
  • 의미없는 리퀘스트라도 수신하게 된다. DDos 공격을 방지할 수 없다.

상대를 확인하는 증명서로 이를 해결할 수 있다.

 

HTTP에서는 통신 상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있다.

 

SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공하고 있다.

증명서는 신뢰할 수 있는 기관의 제 3자 기관에 의해 발행되는 것이다. 이는 서버나 클라이언트가 실재하는 사실을 증명한다.

(증명서의 위조는 기술적으로 상당히 어렵다)

 

여기서 신뢰할 수 있는 제 3자 기관이란 기본적으로 사회에서 인정된 기업이나 조직을 말한다.

 

증명서를 이용해 클라이언트는 다음과 같이 서버가 안전함을 확인할 수 있다.

  1. 클라이언트는 통신을 개시할 때 서버의 증명서를 확인한다.
  2. 증명서를 통해 클라이언트가 통신하고자 하는 서버임을 확인한다.
  3. 정상적인 서버임이 확인되면 통신을 한다.

완전성을 증명할 수 없기 때문에 변조 가능

완전성이란?

정보의 정확성을 가리킨다. 그것을 증명할 수 없다는 것은 정보가 정확한지 아닌지 확인할 수 없음을 의미

 

완전성을 증명할 수 없다는 것은 수신한 내용이 다를 수 있다는 것이다.

HTTP가 완전성을 증명할 수 없다는 뜻은 요청이나 응답이 발신된 후 상대가 받을 때 까지의 사이에 내용이 변조되었다고 하더라도 이 사실을 알 수 없다는 뜻이다.

 

클라이언트에서 사과를 달라고 요청했는데 서버에서 받은 요청문에는 바나나가 적혀있을 수 있다.

반대로 서버에서는 사과를 줬는데 클라이언트에서는 바나나를 받을 수 있다.

 

예를 들어, 웹 사이트의 콘텐츠를 다운로드 했을 때 클라이언트가 받은 파일과 서버의 파일이 일치하는지 아닌지 알 수 없다.

만약 콘텐츠가 변조됐다고 해도 수신한 측에서는 알 수 없다.

 

이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle 공격)이라고 부른다.

 

변조를 방지하려면 안전성을 확인하는 방법으로 MD5나 SHA-1 등의 해시 값을 확인하는 방법과 디지털 서명을 확인하는 방법이 있다.

(확실하면서 편리한 방법은 현재 존재하지 않는다.)

이 방법도 확실히 확인할 수 있는 방법도 아니며 클라이언트를 이용한 유저 자신이 다운로드 받은 파일을 토대로 검사할 필요가 있다.

 

이를 확실하게 방지하기 위해서는 HTTPS를 사용할 필요가 있다.

SSL에는 인증이나 암호화, 다이제스트 기능을 제공하고 있다.

 

HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS 

위의 암호화, 인증, 완전성 보호 같은 약점 해결을 위한 구조를 HTTP에 추가해야할 필요가 있다.

이런 구조를 HTTP에 더한 것을 HTTPS(HTTP Secure)라고 부른다.

 

HTTPS를 사용하고 있는지는 브라우저 화면에서도 간단하게 확인이 가능하다.

당장 브라우저의 URL 왼쪽을 보면 자물쇠 버튼이 있는데(크롬기준) 이는 HTTPS 통신을 하고있다는 것을 의미한다.

 

HTTPS는 SSL의 껍질을 덮어쓴 HTTP

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

HTTP 통신을 하는 소켓 부분을 SSL이나 TLS이라는 프로토콜로 대체하고 있을 뿐이다.

이미지 출처(https://velog.io/@young18/NetworkHTTPS%EC%99%80-SSL-%EC%9D%B8%EC%A6%9D%EC%84%9C)

보통 HTTP는 TCP와 직접 통신하지만 SSL을 사용한 경우에는 HTTP는 SSL과 통신, SSL은 TCP와 통신하게 된다.

 

SSL을 사용함으로써 HTTP는 HTTPS로서 암호화와 증명서와 완전성 보호를 이용할 수 있게 된다.

 

이제부터 HTTPS 의 보안방식이 어떻게 이뤄지는지 알아보자

상호간에 키를 교환하는 공개키 암호화 방식

SSL을 설명하기 전에 암호화 방식에 대해 알아보자.

 

공통키 암호

SSL 에서는 공개키 암호화 방식을 채용하고 있다. 암호화와 복호화에 동일한 키를 사용한다. 이 때 키는 제 3자가 가질 수 없게 해야합니다.

이렇게 암호화와 복호화에 동인한 키를 사용하는걸 공통키 암호라고 부릅니다.

 

공통키 암호화 방식은 상대방에게 키를 건내주지 않으면 당연히 복호화가 불가능하므로 어떤 방식으로든 키를 건내줘야 합니다.

하지만 키를 보내는 과정에서 누군가에게 탈취당하면 치명적입니다.

 

어떻게 하면 안전하게 키를 보낼 수 있을까요?

두개의 키를 사용하는 공개키 암호(비대칭 키 라고도 한다)를 사용할 수 있습니다.

 

공개키 암호(비대칭 키)

공개키 암호에서는 서로 다른 두 개의 키 페어를 사용한다.

  • 비밀 키(private key) : 누구에게도 알려지면 안됨. 해당 키를 통해 복호화 진행
  • 공개 키(public key) : 누구에게나 알려져도 됨. 해당 키를 통해 암호화 진행

공개키 암호를 사용한 암호화는 다음 흐름으로 진행됩니다.

  1. 암호를 보내는 측이 상대의 공개키를 사용해 암호화 진행
  2. 암호화된 정보를 받은 상대는 자신의 비밀키로 복호화 실시

비밀키는 통신으로 보낼 필요가 없으므로 도청에 의해 빼앗길 걱정은 없다.

(암호문과 공개키라는 정보에서 평문을 해독하는것은 불가능에 가깝다. 큰 수의 소인수 분해를 고속으로 할 수 있다면 가능하지만 현재로선 불가능하다)

 

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

공개키 암호(비대칭 키)만 사용하면 안전하게 통신할 수 있겠지만 공개키 암호는 공통키 암호에 비해 처리 속도가 늦습니다. 모든 통신에 공개키 암호를 사용하는 것은 비효율적이다.

 

따라서 두 가지의 장점을 살리기 위해 두 방식을 모두 사용한다.

  1. 공개키 암호를 사용해 공통키를 주고 받는다. (안전하게 주고받을 수 있으므로 제 3자에게 빼앗길 걱정이 없다)
  2. 공통키를 안전하게 주고 받았으므로 이후에는 공통키를 사용해 통신한다.

공개키가 정확한지 아닌지 확인하는 증명서

공개키 암호에도 문제는 있다. 공개키가 진짜인지 아닌지 증명할 수 있는 방법이 없다는 것.

예를 들어, 어떤 서버와 공개키 암호를 사용해서 통신을 시작하려 할 때 수신한 공개키가 본래 서버의 공개키가 아닌 바꿔치기한 공개키라면..?

그리고 해당 공개키로 암호화된 내용이 바꿔치기한 당사자의 손에 들어간다면 비밀키로 복호화까지 할 수 있다.

 

이 문제를 해결하는데 인증 기관(CA: Certificate Authority)과 그 기관이 발행하는 공개키 증명서를 이용한다.

인증 기관이란 클라이언트와 서버가 신뢰하는 제 3자이다.

 

다음과 같은 흐름으로 인증 기관을 이용한다.

  1. 서버의 운영자가 인증 기관에 공개키를 제출
  2. 인증 기관은 제출된 공개키에 디지털 서명을 하고 서명이 끝난 공개키를 만든다.
  3. 공개키 인증서에 서명이 끝난 공개키를 담는다.
  4. 서버는 인증 기관에 의해 작성된 공개키 인증서를 클라이언트에 보내고 공개키 암호로 통신을 한다.
  5. 공개키 인증서를 받은 클라이언트는 인증 기관의 공개키를 사용해 확인한다.(인증 기관의 공개키는 브라우저에 내장되어 있다.)
  6. 클라이언트는 서버의 공개키를 인증한 것이 진짜 인증 기관이라는 것과 공개키가 신뢰할 수 있다는 것을 확인한다.

인증 기관의 공개키는 클라이언트에게 안전하게 보내줄 방법이 어려우므로 브라우저에 내장한 상태로 제품이 출시된다.

 

인증 기관의 실제성을 증명하는 EV SSL 증명서

인증 기관이 실제로 있는 기업인지 확인하는 역할도 있다. 이런 증명서를 EV SSL 증명서라고 한다.

안전한 통신을 하는 HTTPS의 구조

HTTPS의 통신 수순은 다음과 같습니다.

이미지 출처 (https://www.cisp.or.kr/archives/19982)

  1. ClientHello(클라이언트) : 클라이언트가 Client Hello 메시지를 송신하며 SSL 통신을 시작. 메세지에는 클라이언트가 제공하는 SSL 버전을 지정, 암호 스위트(Cipher Suite)로 불리는 리스트(암호화 알고리즘, 키 사이즈) 등이 포함됨
  2. ServerHello(서버): 서버가 SSL 통신이 가능한 경우에는 Server Hello 메세지로 응답한다. 클라이언트와 동일한 SSL 버전과 암호 스위트를 포함.
  3. Certificate(서버): 서버에서 Certificate 메세지를 송신. 메세지에는 공개키 증명서가 포함됨.
  4. Server Hello Done(서버): 최초의 SSL 네고시에이션 부분이 끝났음을 클라이언트에게 통지
  5. ClientKeyExchange(클라이언트): SSL의 최초 네고시에이션이 종료되면 클라이언트가 보내는 메세지. 메세지에는 통신을 암호화하는데 사용하는 Pre-Master secret이 포함. 이 메세지는 3번의 공개키 증명서에서 꺼낸 공개키로 암호화되어 있다.
  6. Key Generation(서버, 클라이언트) : 공통키를 생성한다.
  7. ChangeCipherSpec(클라이언트): 이 메세지는 이후의 통신은 암호키를 사용해서 진행한다는 것을 나타낸다.
  8. Finished(클라이언트): 이 메세지는 접속 전체의 체크 값을 포함. 네고시에이션이 성공했는지 어떤지는 서버가 이 메세지를 올바르게 복호화할 수 있는지 아닌지로 결정된다.
  9. ChangeCipherSpec(서버): 클라이언트와 마찬가지. 이후 통신은 암호키를 사용해서 진행하는 것을 의미
  10. Finished(서버): 클라이언트와 마찬가지. 접속 전체의 체크 값을 포함.
  11. 애플리케이션 계층의 프로토콜에 의한 통신. HTTP 통신

여기에 애플리케이션 계층의 데이터를 송신할 때에는 MAC(Message Authentication Code)이라고 부르는 메세지 다이제스트를 덧붙일 수도 있다. MAC을 이용해서 변조를 감지할 수 있어서 완전성 보호를 실현할 수 있다.

(메세지 다이제스트란? 통신상의 메시지 무결성을 위해 해시 함수를 이용하여 크기를 고정한 검증 값)

 

HTTPS 암호화 정리

  1. 공통키 하나로 평문을 암호화 복호화 전부 다함 -> 공통키를 뺏기면 큰일난다.
  2. 공개키 암호(비대칭 키)를 사용해서 공통키를 건내준다. -> 공개키 암호만 사용하면 느리므로 공개키 암호와 공통키 암호를 함께 사용
  3. 공개키도 변조될 수 있다 -> 인증 기관에서 공개키에 서명하고 인증서에 추가 -> 증명된 공개키 완성
  4. 클라이언트는 서버로 부터 받은 공개키 인증서를 인증기관의 공개키를 사용해 인증기관에 확인을 요청 -> 인증기관의 공개키는 브라우저에 내장됨

HTTPS 의 암호화를 공부하면서 아래의 느낌을 받았다. 인증에 인증에 인증이 필요하다.