ness

...

HTTPS

5 분 소요

HTTPS 란?

위키 의 정의에 따르면,

  • HTTPS (Hypertext Transfer Protocol Secure) 는 HTTP(Hypertext Transfer Protocol) 에 보안을 강화한 것
  • HTTP 프로토콜에 TLS(Transport Layer Security), SSL(Secure Sockets Layer) 을 이용하여 암호화를 적용한 버전 (HTTP 의 암호화 버전)
  • HTTPS 는 HTTP over TLS(SSL) 이라고 불림

HTTP vs HTTPS

No Image

  • HTTP는 전송 데이터를 암호화 하지 않으므로 중간자 공격에 취약
    • 공격자는 사이트의 중요한 정보를 도청 가능
    • 공격자가 웹 페이지를 수정하여 맬웨어 or 광고를 주입가능
  • HTTPS 는 TLS 를 이용하여 전송 데이터를 암호화 함으로써 공격을 방어 가능
    • HTTPS 는 URL, 쿼리 스트링, 헤더 및 쿠키 등을 암호화하여 전송
    • HTTPS 는 호스트와 포트는 TCP/IP 계층의 일부 이므로 암호화 할 수 없음
PROTOCOL URL PORT
HTTP http:// 80
HTTPS https:// 443

TLS(SSL) 란 ?

  • TLS(Transport Layer Security)는 두 컴퓨터 간에 통신에서 응용 프로그램 간의 인증, 개인정보 및 무결성을 제공하는 암호화 프로토콜
  • TLS 는 웹 브라우징, 이메일, VoIP 등에 가장 널리 사용되는 암호화 프로토콜
  • SSL 은 Netscape 사에서 처음 개발했지만, 그 이후 IETF 에서 SSL 3.1 버전을 인수하여 공개 했고 TLS 1.0 으로 릴리즈 했음
  • SSL 과 TLS 를 혼용해서 사용하고 있지만, 정식 명칭은 TLS

TLS 장점(목적)

  • 통신 내용을 공격자에게 노출되는 것을 막을 수 있음 (도청 방지)
  • 통신 내용의 악의적인 변경을 방지 (위조 방지)
  • 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지를 판단 가능
    • 요청한 서버가 위조 사이트 아님을 보증 (피싱 방지)
    • 서버가 신뢰할 수 없는 인증서를 사용한다면 브라우저는 사용자에게 경고 메시지를 출력

디지털 인증서

  • 클라이언트와 서버 같은 엔티티의 ID 를 제3자 가 보증해주는 전자화된 문서
  • 클라이언트는 웹 서버가 제공한 인증서를 제3자 에게 요청하면 제3자 는 해당 웹 서버를 보증
  • 제3자는 CA(Certificate Authority) 로써 신뢰할 수 있는 공인된 기업

CA (Certificate Authority)

  • 클라이언트가 접속하려는 서버가 의도한 서버가 맞는지 보장해주는 민간기업
  • CA 는 신뢰성이 엄격하게 공인된 기업들만이 참여 가능
  • TLS(SSL) 이용하려는 서비스는 CA 를 통해서 인증서를 구입해야함
  • CA의 개인키는 절대로 유출되어서는 안됨 (이것이 노출되어 파산한 회사도 있음)

TLS(SSL) 인증서 내용

크롬에서 Github 인증서

No Image
No Image

  • 서비스 정보
    • 이 영역은 해당 서비스(github)에 대한 정보
    • CA 에서 인증서를 구입하는 서비스는 서비스 도메인, 공개키와 같은 정보를 인증서를 구입할때 제출함
  • 발급자 정보
    • 인증서를 발급한 CA 정보, 만기일 등의 정보
    • 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 확인하기 위해서 사용
  • 공개키 정보
    • 공개키의 알고리즘, 공개키의 내용 등의 정보
    • 클라이언트가 서버와 통신할 때 사용할 공개키와 그 공개키의 암호화 방법들의 정보
  • 전자서명
    • CA 가 해당 서비스(github) 을 식별하기 위해서 사용하는 정보

TLS(SSL) 암호화 방법

TLS 의 암호화는 대칭키 방식과 공개키 방식을 혼합해서 사용함

대칭키

  • 동일한 키로 암호화와 복호화를 하는 방법
  • 암호를 주고 받는 사람들 사이에 대칭키를 전달하는 것이 어려움
  • 대칭키 유출되면 공격자도 암호화 내용을 복호화 할 수 있기 때문

공개키

  • 대칭키 방식의 단점을 보완하고자 나온 방법
  • 공개키는 대칭키와 달리 공개키, 개인키 2개의 키를 이용한 방법
  • 개인키는 자신만이 가지고 있고, 공개키는 타인에게 제공
  • 공개키를 이용해서 암호화, 개인키를 이용해서 복호화하는 방법
  • 즉, 개인키가 없으면 복호화 할 수 없음
  • 공개키 암호화는 개인키 암호화보다 많은 컴퓨터 자원을 사용하는 단점이 있음

TLS(SSL) 기술 스택

No Image

  • TLS 는 위 그림에서 처럼 TCP 계층과 HTTP 계층 사이에서 동작
  • TLS 의 가장 기본적인 부분은 레코드 프로토콜

레코드 프로토콜의 하위 프로토콜

  • Handshake 프로토콜: 이 프로토콜은 보안 연결을 위한 매개변수를 설정하는데 사용함
  • Application 프로토콜: handshake 프로세스 이후 시작되며 클라이언트와 서버간의 데이터가 안전하게 전달됨
  • Alert 프로토콜: 오류, 안정성 문제 등이 있을때 한쪽에서 다른쪽에 noti 하기 위해서 사용
  • Change chiper spec 프로토콜: 암호화 매개변수를 수정하기 위해서 사용함
  • Heartbeat 프로토콜: 커넥션이 여전히 활성상태인지 확인하기 위해서 사용됨

alert, change chiper spec, heartbeat 프로토콜은 특정상황에 필요할 때 사용되어짐
여기서 중요한 것은 handshake와 application 프로토콜

TLS Handshake 프로토콜

기본 TLS Handshake

  • 이 유형은 서버만 인증되고 클라이언트는 인증되지 않음

No Image

  • TLS Handshake 는 우선 TCP 3-way Handshake 이후에 발생함
    • TLS 는 TCP 위에서 동작하기 때문에 ..
  • 클라이언트: client hello
    • 클라이언트가 지원하는 TLS 버전, 지원하는 암호화 방식, 클라이언트가 생성한 랜덤 데이터, 세션 ID 등을 전송
    • 세션 아이디 : 이미 TLS handshake 를 했다면, 비용과 시간을 절약하기 위해 기존 세션을 사용함 (약식 TLS handshake)
  • 서버: server hello (certificate)
    • 서버가 선택한 세션 ID, 선택된 암호화 방식, 서버가 생성한 랜덤한 데이터, 인증서 등을 전송
    • 서버는 인증서를 전송할 때 개인키로 암호화하여 전송 - 해당 서버가 공인된 CA 에게 보증받는 인증서임을 보장
    • 위에서 봤지만, 인증서에는 서비스 정보, 공개키, CA 정보 등을 포함한다
  • 서버: server hello done
    • 서버는 클라이언트에게 server hello 가 종료되었음을 알려줌
  • 클라이언트: 인증서 확인
    • 클라이언트(브라우저)는 먼저 인증서를 확인하여 자신의 CA 리스트에서 CA 를 확인
    • 브라우저는 인증서를 공개키로 복호화 하여 인증서 내용을 확인
    • 인증서를 공개키로 복호화 가능하다는 것은 해당 CA 가 발급한 개인키로 인증서가 암호화 된 것을 의미 - 신뢰할 수 있는 서버임을 보증
  • 클라이언트: client key exchange
    • 클라이언트는 premaster secret 을 생성 (생성방법은 cipher suite에 의존적임)
    • 클라이언트는 premaster secret 을 서버의 공개키를 이용하여 암호화하여 서버에 전송
    • 서버는 암호화된 premaster secret 을 개인키로 복호화
    • 서버는 premaster secret 과 이전에 클라이언트로 부터 전송된 랜덤 데이터를 이용하여 master secret 을 생성
    • 클라이언트도 premaster secret 과 이전에 서버로 부터 전송된 랜덤 데이터를 이용하여 master secret 을 생성
  • 클라이언트: change chiper spec
    • 클라이언트는 암호사양 변경되었다는 메시지를 전송
    • 이제부터 전송하는 클라이언트의 모든 데이터는 대칭키 암호화 방식을 이용
  • 클라이언트: finished
    • 클라이언트는 handshake 종료 메시지를 전송
    • 해당 데이터는 대칭키로 암호화된 데이터
  • 서버: change chiper spec
    • 서버도 암호사양 변경 수신했다는 정보를 전송
    • 이제부터 서버도 모든 전송 데이터를 대칭키 암호화 방식으로 전송
  • 서버: finished
    • 서버도 handshake 종료 메시지를 전송
    • 해당 데이터는 대칭키로 암호화된 데이터

클라이언트 인증 TLS Handshake

  • 이 방법은 클라이언트 인증서를 서버가 사용해야 하는 경우에 사용하는 방법 (일반적 x)
  • server hello 단계에서 서버가 인증서를 전송할 때, 클라이언트도 인증서를 보내라는 요청을 함께 전송
  • 그러면 클라이언트는 server hello done 이전에 클라이언트의 인증서 정보를 클라이언트의 개인키를 이용하여 암호화하여 전송
  • 서버는 해당 인증서 내용이 유효한지 확인하고 유효하면 server hello done 을 전달함
  • 나머지 단계는 기본 TLS Handshake 와 같음

약식 TLS Handshake

  • client hello 전송시에 클라이언트는 session ID 를 함께 전송하는데, 서버가 해당 session ID 를 미리 알고 있는 경우에 해당
  • 서버가 session ID 를 알고 있으므로 인증서 및 키 교환 단계를 건너 뛰게 됨

세션: 실제 데이터 전송

  • 클라이언트: 데이터 요청
    • 클라이언트는 요청 데이터를 대칭키 방식으로 암호화하여 전송
  • 서버: 데이터 응답
    • 요청 데이터를 대칭키 방식으로 복호화한 뒤 적절한 응답 데이터를 대칭키로 암호화하여 전송

생활코딩 블로그 에서는 대칭키를 session key 라고 설명되어 있으나 …
다른 블로그들 자료들에서는 master secret 을 이용 하는것으로 보임

comparitech, acunetix

Master secret

  • 전송되는 모든 레코드들을 보호하기 위한 목적으로 사용됨
  • 클라이언트와 서버 모두 master secret 을 가지고 있으며 각 3개의 key 가 있음
  • MAC(Message Authentication code): 암호화된 메시지들이 상대방이 암호화한것이 맞는지 무결성을 검증할 때 사용하는 인증

Master secret 구성

  • 클라이언트 쓰기 MAC key: 서버에서 클라이언트가 보낸 데이터의 무결성을 확인하는데 사용되는 key
  • 클라이언트 쓰기 암호화 key: 서버는 클라이언트에서 전송된 데이터를 암호화 하는데 사용되는 key
  • 클라이언트 쓰기 IV key: 서버에서 AEAD 암호화에 사용되는 key (다른 암호화 알고리즘에서는 사용되지 않음)
  • 서버 쓰기 MAC key: 클라이언트가 서버에서 보낸 데이터의 무결성을 확인하는데 사용되는 key
  • 서버 쓰기 암호화 key: 클라이언트는 서버에서 전송된 데이터를 암호화 하는데 사용되는 key
  • 서버 쓰기 IV key: 클라이언트에서 AEAD 암호화에 사용되는 key (다른 암호화 알고리즘에서는 사용되지 않음)

TLS 와 OSI 7 계층

  • OSI 7 계층은 통신 시스템 및 프로토콜을 보는 방법을 표준화 한것
  • 이것은 하나의 모델일 뿐, 모든 프로토콜이 해당 모델을 지키고 있는 것은 아님 …
  • 위에서 보는것 처럼 TLS 는 OSI 모델을 따르고 있지 않음
  • 물론 TLS 는 TCP 위에서 동작하므로 Transport 계층 처럼 보일 수 있으나 ..
  • HTTP 프로토콜 위에 동작함으로 순수 Transport 계층으로 볼수 없음 …

TLS 와 OSI 관련 질문들 …

TODO

  • TLS 사용 하기
  • TLS 보안 문제 …

Reference

참고