Post

네트워크 - HTTPS

Posted Updated
By MilkTea24 13 min read

1. 암호화 방식

TLS를 이해하기 위해서는 대칭키/비대칭키 암호화 방식의 차이를 인식할 필요가 있다. 어떠한 평문을 다른 사람에게 노출되지 않고 안전하게 전송하고 싶다면 평문을 암호화할 수 있다. 암호문은 키를 가진 제한된 사람만 이를 해독하여 평문으로 바꿀 수 있다. 이 키의 종류에 따라 대칭키 암호화, 비대칭키(공개키) 암호화로 분류할 수 있다.

대칭키 암호화

대칭 키 암호화는 암호화, 복호화를 모두 동일한 키를 이용하는 시스템이다. 대칭 키 암호화는 비대칭키 암호화에 비해 계산이 간단하여 빠른 처리 속도를 보인다. 따라서 대용량 데이터를 암호화할 때 대칭키 암호화 방식을 자주 사용한다.

대칭키 암호화의 단점은 키 관리가 어렵다는 점이 있다. 암호화된 데이터를 주고받는 모든 당사자가 같은 키를 공유해야 하기 때문에 공유하는 사람이 많을 수록 키의 분실, 유출 위험이 어렵다. 이 키를 어떻게 안전하게 공유할 지에 대한 문제도 있다.

대표적인 예시로 DES, AES 알고리즘이 있다.

비대칭키 암호화

디피-헬만이 제안한 알고리즘에서 출발한 암호화 시스템이다. 보내는 사람, 받는 사람 둘 중 한명은 본인만 아는 비밀키를 사용하고 나머지 한명은 모두에게 공개된 공개키를 사용한다.

밥이 앨리스에게 데이터를 보낸다고 하자.

  1. 앨리스는 공개키-개인키 한 쌍의 키를 가지고 있고 개인키는 본인만 알고 있다.
  2. 밥은 앨리스의 공개키로 데이터를 암호화하여 전송한다.
  3. 전송한 데이터는 앨리스의 개인키 없이는 복호화할 수 없으므로 앨리스만이 데이터를 확인할 수 있다.

이 비대칭키 암호화의 장점은 키를 공유함으로써 발생하는 위험이 없다는 점이다. 보내는 사람은 공개키를 이용하여 암호화하면 되므로 비밀키를 받을 필요가 없다. 따라서 비밀키를 공유함으로써 발생하는 키의 분실, 유출 위험 등에서 자유롭다.

비대칭키 암호화 알고리즘의 대표적인 예시로 RSA가 있다.

CA(Certificate Authority)

이 때 인터넷에 돌아다니는 공개키가 정말 믿을만 한가에 대한 문제가 있다. 밥의 공개키인줄 알고 암호화하여 전송하였는데 공격자의 공개키일 수 있는 것이다.

따라서 제 3의 기관이 개입하여 어떤 사람, 단체의 신원을 확인한다. 일단 신원을 확인하여 신뢰할 수 있는 사람임이 확인되면 CA는 공개키와 신분확인서를 결합한 인증서를 만든다. 이 인증서에는 CA가 전자서명을 하여 CA 외에는 수정할 수 없다.

전자 서명

데이터 보안에서 다른 사람에게 데이터를 노출시키지 않는 것과 더불어 다음의 사항도 아주 중요한 요소이다.

  • 메세지가 정말 밥이 보낸 것인가? 누군가가 밥을 위장하여 보낸 것 아닌가?
  • 정말 밥이 보낸 것이 맞다면 중간에 누가 악의적으로 이 데이터를 위조하지 않았는가?

전자서명은 이러한 문제를 해결하기 위해 도입되었으며 전자서명을 함으로써 서명자를 입증할 수 있고, 위조할 수 없도록 한다. 비대칭키 암호화를 이용하면 전자서명을 구현할 수 있다.

밥이 앨리스에게 데이터를 보낼 때 자신이 보냈음을 보증하고 싶다고 하자.

  1. 밥은 자신의 개인키로 데이터를 암호화하여 전송한다.
  2. 전송한 데이터는 밥의 공개키로 언제든지 열람할 수 있다.
  3. 하지만 열람한 데이터를 다시 수정할 때 밥이 수정했다고 보장하기 위해서는 밥의 개인키로 암호화해야 한다.
  4. 따라서 밥의 개인키 없이는 밥이 보냈다고 위장할 수 없고 또한 데이터를 위조할 수 없다.

이 과정에서 전체 평문을 암호화하면 많은 비용이 들 수 있다. 어차피 공개키로 얼마든지 열람을 할 수 있으므로 전체 평문을 암호화하는 대신 평문으로부터 생성한 해시 함수를 암호화하여 전달한다. 받는 사람은 공개키로 복호화된 해시 함수 값과 받은 평문을 바탕으로 한 해시 함수 값이 일치하는지 파악하여 위조되었는지 확인할 수 있다.

2. SSL/TLS

TLS는 기존 TCP에 암호화를 적용하여 기밀성, 데이터 무결성, 종단점 인증 등의 보안 서비스를 제공하는 향상된 TCP 버전이다. 처음에 TCP 보안을 위해 SSL이 등장했고 이를 보완한 TLS가 현재 널리 사용되고 있다.

네트워크 통신에서 기밀성, 데이터 무결성, 종단점 인증 기능을 제공하지 않는다면 다음과 같은 문제점이 있다. 예를 들어 밥이 앨리스사의 사이트에서 물건을 주문한다고 하자.

  1. 기밀성 X : 공격자가 밥이 입력한 카드 정보 등을 가로채어 악용할 수 있다.
  2. 데이터 무결성 X : 공격자가 밥이 입력한 주문 수량을 수정해서 주문했던 기존 수량보다 훨씬 많은 물건을 구매하게 할 수 있다.
  3. 종단점(서버) 인증 X : 공격자가 앨리스사의 사이트를 가장한 피싱 사이트를 만들어 입력한 카드 정보 등을 가로챌 수 있다.

img.png

이러한 TLS는 HTTPS 뿐만 아니라 TCP 상에서 일어나는 어떠한 애플리케이션에서 사용할 수 있다.

TLS 핸드셰이크 과정

img.png

TLS 과정에서 전체 데이터 스트림을 여러 레코드로 쪼개고 레코드의 순서와 각 레코드의 무결성 검사를 위한 HMAC을 덧붙인 후 암호화한다. 아래는 TLS 1.2 버전을 기준으로 한다.

  1. TCP 연결을 구축하는 과정을 거친다.
  2. Client Hello: 클라이언트는 넌스(랜덤한 값)와 함께 자신이 지원하는 암호화 알고리즘의 목록을 보낸다.
  3. Server Hello: 이를 바탕으로 서버는 대칭키, 공개키, HMAC 알고리즘을 선택한다. 서버는 선택한 결과와 자신의 인증서, 서버 넌스를 클라이언트에 돌려준다.
  4. Key Exchange: 클라이언트는 서버의 인증서를 확인하고 PMS(Pre-Master Secret)을 생성한다. 그리고 서버의 공개키를 바탕으로 암호화한 후 PMS를 서버로 전송한다.
  5. Finished: 클라이언트와 서버는 동일한 키 유도 함수를 사용하여 PMS와 클라이언트, 서버 넌스로부터 독립적으로 MS를 계산한 후 2개의 암호화 키와 HMAC 키를 얻는다.
  6. 클라이언트와 서버는 각자 가지고 있는 암호화 키와 HMAC 키로 전송할 데이터를 암호화하고 받은 데이터를 복호화한다.

따라서 TLS 핸드셰이크는 TCP 연결 과정을 제외하면 두번의 RTT가 발생한다.

왜 클라이언트와 서버는 각자 생성한 넌스를 교환할까?

랜덤한 값이 없으면 재전송 공격(Replay Attack)의 위험이 있다. 공격자가 전송자 밥과 수신자 앨리스 사이 모든 메세지를 엿듣고 다음날 정확히 동일한 데이터를 다시 전송한다. 이 때 랜덤한 값이 개입하지 않으면 앨리스는 밥이 동일한 데이터를 또 다시 저장할 것이라고 판단한다.(예를 들면 똑같은 물건을 재주문)

하지만 TLS 연결마다 서로 다른 넌스를 교환하면 랜덤한 값인 넌스를 바탕으로 암호화 키가 생성되므로 다음 날 사용되는 암호화 키가 달라진다. 따라서 공격자가 똑같은 데이터를 다시 전송하더라도 암호화 키가 달라지기 때문에 무결성 검사에 실패한다.

Reference

https://www.entrust.com/ko/resources/learn/what-is-https

James F. Kurose,Keith W. Ross 편저, 최종원 외 7인 옮김, 컴퓨터 네트워킹 하향식 접근 8판, 퍼스트북

Network
HTTPS
This post is licensed under CC BY 4.0 by the author.

© . Some rights reserved.

Using the Chirpy theme for Jekyll.