TL;DR

• HTTP vs HTTPS
• SSL/TLS 동작방식
• HSTS

HTTP vs HTTPS

HTTP

• HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동
• 포트 넘버 80
• 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜 이라 해커 공격 및 스니핑에 매우 취약
• Stateless, Connectionless
  • 과거 트랜잭션에 대한 정보 또는 참조가 저장되지 않는 연결 형태 (서버에 연결하고 요청해서 응답 받으면 연결 끊음)
  • 요청(Request)과 응답(Response)으로 구성
  • 각 메세지는 Method, Path, Version, Headers, Body 등으로 구성
  • 장점 : 접속 유지 최소화, 불특정 다수를 대상으로 하는 서비스에 유리
  • 단점 : 연결을 끊어버리기 때문에 클라이언트의 이전 상태를 알 수 없음 (쿠키 사용해서 보완)
• HTTP 1.1 Connection: Keep-Alive 옵션 이전에는 connectionless가 기본이었으나 keep-alive 옵션을 주면 연결을 유지할 수 있다.

HTTPS

• HTTP에 데이터 암호화가 추가된 프로토콜

• SSL/TLS를 통해 암호화해서 컴퓨터 네트워크를 통한 통신을 보안하도록 설계된 웹 통신 프로토콜

  • 기존 HTTP는 TCP와 직접 통신하지만 HTTPS는 SSL/TLS와 통신함

• 포트 넘버 443

• 제 3자 인증, 공개키 암호화, 비밀키 암호화를 사용해 보안

• 접속한 서버가 신뢰할 수 있는지 확인하기 위해 CA로부터 SSL 인증서 발급받아야 함

  • CA(Certificate Authority) : SSL 인증서를 보장해주기 위한 외부 기관
  • 인증서에는 사이트의 정보와 서버의 공개키를 포함

• 단점 :

  1. SSL을 사용하기 때문에 처리가 늦어짐

     • HTTP를 기반으로 웹서버와 통신을 하되, 암호화 통신을 위한 별도의 협의 과정을 거쳐야 하고,

     • 서버와 클라이언트 모두 암복호화 처리가 필요해 CPU나 하드웨어 리소스 소비가 불가피함

     • HTTPS는 HTTP에 비해 약 2~100배 느리다고 한다.

  2. 인증 기관을 통해 인증서를 구입해야 함 (비용 문제)

HTTPS의 동작 과정

• HTTPS 연결 과정(TLS Handshaking)에서는 먼저 공개키 암호화 방식을 사용해 클라이언트-서버간 세션키 교환

• 세션키 교환이후 데이터 송/수신 과정에서는 세션키를 사용한 대칭키 암호화 방식으로 데이터를 주고 받음

  세션키: 주고받는 데이터를 암호화하기 위해 사용되는 대칭키

SSL (Secure Sockets Layer)

• 인터넷 상에서 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜
• 응용 계층과 전송계층 사이에서 독립적으로 동작
  • Application은 SSL을 TCP로 인식하고, TCP는 SSL을 Application으로 인식

암호화

• SSL은 보안과 성능 상의 이유로 두 가지 암호화 기법을 혼용해서 사용함
• 키(Key) : 암호를 만드는 행위인 암호화를 할 때 사용하는 일종의 비밀번호

1) 대칭키

• 암호화와 복호화에 같은 암호키를 사용하는 기법
• 암호화 및 복호화가 빠름
• 대칭키를 공유해야 하기 때문에 대칭키가 유출되는 해킹의 위험에 노출될 수 있음

2) 공개키

• 암호화와 복호화에 사용하는 암호키를 분리
  • 비밀키 (Private Key) : 자신이 가지고 있는 고유한 암호키
  • 공개키 (Public Key) : 대중에 공개되는 키. 비밀키로만 복호화할 수 있음.

3) 대칭키와 공개키를 이용한 SSL 암호화 기법

• 암호화는 대칭키 방식을 사용하고, 키를 전달하는 방식은 공개키 방식을 사용함

1. B는 A의 공개키를 이용해 B의 대칭키를 암호화 해서 전달
2. A도 위와 같은 절차 수행
3. A와 B는 서로의 대칭키를 보유하고 있기 때문에 서로의 대칭키로 암호화해서 전달 가능
   • 서로의 대칭키로 암호화를 하기 때문에 비용 감소 (공개키 단점 보완)
   • 공개키 방식을 통해 키 전달의 보안 위험 해결 (대칭키 단점 보완)

실제 사용 시나리오

1. 인터넷 사이트는 자신의 정보와 공개키를 인증기관(CA)에 제출

2. 인증기관은 검증을 거친 후 사이트 정보와 공개키를 인증기관의 개인키로 암호화 (사이트 인증서)

3. 인증기관은 웹 브라우저에게 인증기관의 공개키를 제공

4. 사용자가 웹 브라우저로 사이트 접속 시, 사이트는 인증서를 웹 브라우저에게 보냄

   (사이트 인증서에는 인증기관의 개인키로 암호화된 사이트의 정보 및 공개키가 있음)

   
   

5. 웹 브라우저는 인증 기관의 공개키로 서버 인증서를 해독해 검증

6. 여기서 얻은 사이트 공개키로 웹 브라우저의 대칭키를 암호화해서 보냄

7. 사이트는 공개키로 암호화 된 내용을 개인키로 복호화해서 사용자의 대칭키를 얻음

8. 사이트와 웹 브라우저는 서로의 대칭키를 이용해 암호문을 주고 받음

☝️ 여기서 잠깐!

SSL 인증서 발급 과정

• 서버는 인증기관(CA)에 돈을 지불하고, 공개키를 저장하는 인증서 발급을 요청
• CA 기업은 CA 기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고 CA기업의 개인키로 암호화해 전달

• 인증서는 CA의 개인키로 암호화되었기 때문에 신뢰성을 확보할 수 있고,
• 클라이언트는 서버의 공개키로 데이터를 암호화했기 때문에 서버만 복호화가 가능함
• 클라이언트(브라우저)에는 인증된 CA 기관 정보들이 사전에 등록되어 있어 인증된 CA 기관의 인증서가 아니면 "NOT SECURE" 표시가 화면에 출력된다.

✌️ 여기서 잠깐!

CA(Certificate Authority) 는 누가 하나?

아무 기업이나 할 수 있는 것이 아니라 신뢰성이 엄격하게 공인된 기업들만 참여할 수 있다.

IdenTrust with 48.9 / DigiCert with 18.7 / Sectigo with 15.5 - (위키피디아 참조)

TLS(Transport Layer Security)

• TLS는 안전한 인터넷 통신을 위한 암호화 프로토콜

• 목적 : TCP로 데이터 보내는데, 송수신자 외에 데이터를 보거나 조작하지 못하도록 하겠다!

• TLS를 사용하는 애플리케이션 프로토콜은 끝에 S가 붙는다.
  • TLS 기반의 HTTP는 HTTPS
  • TLS 기반의 FTP는 FTPS

☝️여기서 잠깐! SSL은 Netscape에서 만든 솔루션으로 ver3.0이 나왔을 때, IETF에서 인터넷 표준을 정하자면서 TLS를 제안했다. TLS 버전 1.0은 SSL 버전 3.1로서 개발을 시작했지만 Netscape와 더 이상 연관이 없음을 명시하기 위해 발표 전에 프로토콜의 이름이 변경되었음. 다만 SSL과 TLS 용어를 혼용해서 많이 사용함.

제공하는 보안 서비스

1. 기밀성 : 대칭키 암호화 방식을 사용하게 되면 기밀성을 제공할 수 있습니다.
2. 무결성 : 메시지 인증 코드(MAC)를 통해 메시지 위/변조 여부 확인 가능
3. 인증 : 연결 초기 설정에서 주고 받는 인증서를 통해 신뢰할 수 있는 서버인지 인증가능

• 클라이언트와 서버가 각각 3개씩 총 6개의 Key 가 필요하다.

  • MAC secret : HMAC 사용해서 필요함

  • Key : 암복호화를 위한 Key

  • IV(Initialization Vectors) : CBC 모드에서 사용

☝️여기서 잠깐!

MAC: Message Authentication Code 이란?

• 상대방이 보낸 암호화데이터가 변조된 것인지, 아닌지를 판단하는 역할
• 메시지 + 대칭키를 MAC 알고리즘을 적용하여 MD(Message Digest) 생성 후 메시지와 함께 보냄
• 수신자는 전달받은 메시지를 대칭키와 함께 MAC 알고리즘을 적용시켜 MD 생성 후 자신이 받은 MD와 일치여부 검증

TLS의 세부 프로토콜

• Handshake 🌟 : 양쪽 간에 연결을 설정할때 보안 협상을 위한 프로토콜
• Change Cipher Spec : 보안 파라미터를 변경하거나 적용할때 사용.
  • 예를 들어 대칭키 알고리즘을 변경할때 이 프로토콜을 사용
• Alert : 오류 전송
• Record : 데이터 전송
  1. 응용 층 데이터를 Fragment로 자르고
  2. (압축한 후) MAC 추가
  3. 암호화 진행하고, TLS Record header 붙이기
  4. TCP 통해 전송

• Heartbeat Protocol : 주로 상대방이 응답 가능한지 확인하기 위해 사용
  • TLS는 아닌데, 이 정보를 Record 프로토콜에 실어서 전달할 수 있다.
  • synchro 가리키는 H/W 또는 S/W에서 생성되는 주기적인 신호
  • Handshake 프로토콜 Phase1에서 사용여부를 결정한다.
    • 수신자가 Alive 인지 확인
    • 의미 있는 정보 교환을 지금 못하더라도 연결은 유지하고 싶은 경우

TLS 핸드셰이크

• 사용할 TLS 버전(TLS 1.0, 1.2, 1.3 등) 지정
• 사용할 암호화 알고리즘 결정
• 서버의 공개 키와 SSL 인증서 기관의 디지털 서명을 통해 서버의 ID를 인증한다.
• 핸드셰이크가 완료된 후에 대칭 암호화를 사용하기 위하여 세션 키를 생성

1. Client Hello

• 클라이언트가 서버로 “헬로” 메시지를 전송하면서 핸드셰이크를 개시

  1. 클라이언트(브라우저)가 지원하는 TLS 버전

  2. 클라이언트(브라우저)에서 사용가능한 암호화 방식 모음(cipher suite)

     예를 들어 TLS_RSA_WITH_AES_128_GCM_SHA256이면, 키 교환 알고리즘은 RSA, 대칭키 알고리즘은 AES_128_GCM, Hash 알고리즘은 SHA256을 사용한다는 것

  3. 클라이언트가 생성한 임의의 난수(숫자)

  4. 만약에 이전에 TLS 핸드 셰이크가 완료된 상태라면, 그때 생성된 세션 아이디(Session ID)

  ☝️여기서 잠깐! 암호화 방식 모음 cipher suite 이란?

  보안의 궁극적 목표를 달성하기 위해 사용하는 방식을 패키지 형태로 묶어놓은 것

  • 안전한 키교환
  • 전달 대상 인증
  • 암호화 알고리즘
  • 메시지 무결성 확인 알고리즘

2. Server Hello

• 클라이언트 헬로 메시지에 대한 서버의 응답

  1. 서버의 공개키가 담긴 SSL 인증서.

     이 인증서는 CA의 비밀키로 암호화되어 발급된 상태

  2. 클라이언트의 암호화 방식 모음 중에서, 서버가 지원하고 선택한 암호화 방식(cipher suite)

  3. 서버가 생성한 임의의 난수(숫자)

3. Server certificate (서버 인증서 확인)

대부분의 브라우저에는 공신력 있는 CA들의 정보와 CA가 만든 공개키가 이미 설치되어 있다. 그래서 서버가 보낸 SSL 인증서가 정말 CA가 만든 것인지 확인하기 위해 내장된 CA 공개키로 암호화된 인증서를 복호화해본다.

• 클라이언트가 서버로부터 받은 SSL 인증서를 인증서 발행 기관의 공개키를 통해 검증
  • 서버가 인증서에 명시된 서버인지
  • 클라이언트가 상호작용 중인 서버가 실제 해당 도메인의 소유자인지

4. Client key exchange (pre-master-secret 전달)

• 브라우저가 자신이 생성한 난수와 서버가 생성한 난수를 사용하여 pre-master-secret이라고하는 무작위 바이트 문자열을 생성
• pre-master-secret을 서버의 공개키로 암호화하여 서버로 전송

5. Pre-master Secret 복호화

• 서버는 자신의 개인키를 사용하여 브라우저가 보낸 pre-master-secret을 복호화

6. Handshake 종료 및 HTTPS 통신 시작

• 세션 키 생성 : 이것으로 브라우저와 서버 사이에 주고 받는 데이터를 암복호화
  • HTTPS 통신이 완료되는 시점에서 서로에게 공유된 세션 키를 폐기
• 클라이언트와 서버가 각각 세션 키로 암호화된 “완료” 메세지를 전송함으로 준비 완료를 알리고
• HTTPS 통신 시작 (세션 키 이용한 대칭키 암호화)

HSTS(HTTP Strict Transport Security)

• Web Site에 접속할 때, 강제적으로 HTTPS Protocol로만 접속하게 하는 기능
• 즉, HTTPS Protocol을 지원하는 Web Site에서 자신은 HTTPS만 사용해서 통신할 수 있음을 Web Browser에게 알려 주는 기능

HSTS 기능을 사용하는 목적

리다이렉트 응답을 통한 HTTPS 강제 방법의 한계

• 웹 브라우저가 HTTP Protocol 로 특정 도메인에 접속을 시도하는 경우, 해당 도메인이 HTTPS 프로토콜만을 지원하는 웹사이트라면 ”301 Redirect” 또는 ”302 Redirect” 응답을 보내 웹 브라우저가 HTTPS로 다시 접속하라고 redirect 하여 HTTPS를 통해 웹사이트와 통신한다.
• 그러나 이 경우 해커와 같은 공격자가 중간자공격(MITM attack)을 하여 중간에 Proxy Server를 두고 사용자와는 HTTP 통신을 하고 실제 사이트와는 HTTPS 통신을 하는 문제가 발생할 수 있다.
• 즉, 사용자가 실제 사이트와 주고 받는 모든 정보는 공격자에게 노출될 수 있다. 이러한 공격 방지하기 위하여 HSTS를 사용해야 한다.

즉 사용자가 실수로 HTTPS Protocol을 지원하는 Site를, HTTP Protocol로 접속 했을 때, 중간자 공격에 의해, HTTP Protocol을 사용한 통신을 하게 되고, 이로 인해 통신 정보가 공격자에게 노출이 되는 것을 방지하고자 하는 목적

HSTS 기능의 동작

• HSTS를 지원하는 Web Browser는 내부에 HSTS List를 보유하고 있다.
• 즉 HTTPS Protocol을 사용해야만 하는 Web Site에 대한 정보를 가지고 있다.

1. 클라이언트가 HTTP로 접속을 시도하는 경우, 먼저 브라우저에서 HSTS 설정된 도메인인지 확인(HTTP 요청 보내지 않음)
2. HSTS된 사이트에 대해 브라우저는 HTTPS로 서버에 요청한다. (중간자는 SSL로 암호화된 패킷을 도청할 수 없다.)
3. 서버가 HTTPS 요청에 대한 응답을 보낸다.
   • 웹서버는 HTTPS Reply Message에 HSTS Policy를 넣어서 보낸다.
4. 서버로 부터 받은 응답을 통해 HSTS List를 구성한다.
   • HSTS는 HTTPS로 웹 사이트에 접속하기 위해 적어도 한번 웹 서버와 통신을 해야하는데, 통신 전에 미리 HTTPS로 접속하도록 목록을 미리 만들어 놓은 것.
   • 브라우저에서 지원하는 기능이며, 구글 크롬이 주도하는 HSTS Preload List가 주로 사용된다. (크롬 뿐만 아니라 엣지, 사파리, 파이어폭스 등 다양한 브라우저도 이를 지원)
   • 해당 리스트에 사이트가 등록되면 이후 업데이트되는 브라우저는 등록된 도메인을 무조건적으로 HTTPS로 연결하며, HTTPS가 지원되지 않는 경우 연결 자체가 불가하게 된다.

HSTS 적용방법

• HSTS는 웹서버에서 응답해주는 헤더에 최초 포함되어 있는 만큼 웹서버에서 설정 해주어야 한다.
• 설정 방법은 HTTP 응답 헤더에 Strict-Transport-Security라는 필드를 내려주면 된다.
• 해당 응답을 받은 브라우저는 그 사이트에 접속할 때 무조건 HTTPS로만 연결한다.
• HSTS response header 요소
  • max-age=31536000 : HSTS가 브라우저에 설정될 시간. 초단위로, 63072000은 2년을 의미
  • includeSubdomains : HSTS가 적용될 도메인의 서브 도메인에도 HSTS를 적용한다.
  • preload : 브라우저가 해당 사이트를 HSTS 적용 preload list에 추가하도록 한다.

# 예시
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

추가

웹이 받을 수 있는 공격

1. 적합하지 않은 방법으로의 데이터 변경 (무결성)

• 정보 손실 발생
• 암호화 또는 checksum으로 대응

2. 넷 상의 도청, 스니핑 (기밀성)

• 정보 손실과 Privacy 손상
• 암호화 또는 Web proxies(IP 감추기)

3. DoS (user thread 죽이기, 서버에 request 집중되게 하기) - 사용성

• 짜증나고 파괴적인 공격
• 막기 쉽지 않음

4. 정상 사용자로 위장 (데이터 조작) - 인증

• 사용자로 오인함으로 발생 -> 거짓 정보를 믿게 됨
• 암호화 기술을 통해 대응 (인증)

인증기관 CA를 통한 인증을 하는 이유

• 서로간 공개키를 인증하지 못하면 MiM 공격에 취약하기 때문이다.
• HTTPS는 전달 구간에 대한 보안 기술이기 때문에 HTTPS는 유지되지만 전달하는 내용은 고스란히 노출될 수도 있다.

중간자 공격(Man in the middle attack)

• 네트워크 통신을 조작하여 통신 내용을 도청하거나 조작하는 공격 기법

• 클라이언트가 서버의 SSL 인증서를 검증하는 과정을 생략하는 등 불완전하게 구현하는 경우

  공격자가 SSL 프록시를 이용하는 중간자 공격을 통해 정보를 탈취하거나 바꿔치기 하는 등의

  공격이 가능

• Alice ———-[ Trudy ]———- Bob

  • Alice 와 Bob이 통신하려고 하는 상황에서,
  • Alice와 Bob은 서로가 연결됐다고 생각하지만 실제로는 각각 Trudy에게 연결된 상태
  • Trudy는 사이에서 정보를 도청하고 조작한 후 전달한다.

예상 질문

HTTP / HTTPS

HTTP와 HTTPS에 대해서 설명해주세요

HTTP는 웹 상에서 클라이언트와 서버 간에 요청/응답으로 정보를 주고 받을 수 있는 프로토콜이다. 가장 큰 특징은 Connectionless와 Stateless 이다. 그런데, HTTP는 평문 통신이기 때문에 도청이 가능하고 통신 상대를 확인하지 않기 때문에 위장이 가능하다. 또한, 완전성을 증명할 수 없기 때문에 변조가 가능하다. 그래서 이것을 개선하기 위해 HTTPS 가 등장하게 되었다. HTTPS 는 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전의 프로토콜이다. 웹 상에서 정보를 암호화하는 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. SSL 을 사용하여 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

구글 크롬 브라우저에서는 HTTPS 사이트는 ‘안전함’으로 표시하고 HTTP 사이트에 대해서는 ‘안전하지 않음’ 경고 표시를 적용하고 있는데요, 구글은 왜 경고를 표시할까요?

HTTP 서버는 정보를 암호화하지 않은 텍스트로 주고 받기 때문에 해커의 공격과 스니핑에 매우 취약합니다. 이런 보안 문제를 해결하기 위해 서버와 클라이언트의 모든 통신 내용을 암호화하는 HTTPS를 사용해야 합니다.

그렇다면 왜 아직도 HTTP를 사용하는 웹사이트가 있을까요? (HTTPS의 단점)

• HTTPS가 HTTP보다 CPU나 메모리 등 리소스를 많이 소비해 한 서버당 처리할 수 있는 리퀘스트 수가 줄어들기 때문입니다.
• 엑세스가 많은 웹사이트의 경우 암복호화에 대한 부하로 인해 숨겨야 하는 정보만 암호화해 리소스를 절약하기도 합니다.
• 또 하나는, HTTPS를 사용하기 위해서는 인증기관을 통해 증명서를 구입해야 하는데 이 가격이 부담되는 경우 HTTP를 선택해 사용하기도 합니다.

SSL/TLS

SSL은 왜 대칭키와 공개키 암호화 방식을 혼합해서 사용할까요?

대칭키는 암복호화가 빠르지만 대칭키를 공유할 때 해킹의 위험이 있다는 단점이 있고, 공개키는 암호화와 복호화 키를 분리함으로써 공유의 문제가 없지만 암복호화에 비용이 더 든다는 단점이 있습니다.

이 둘을 혼합해서 사용함으로써 서로의 단점을 보완할 수 있습니다.

• 공개키 방식을 통해 키 전달의 보안 위험 해결하고 (대칭키 단점 보완)

• 서로의 대칭키로 암호화를 함으로 비용을 감소시킵니다. (공개키 단점 보완)

일반적으로 인증된 기관(CA)에는 어떤 곳이 있고, 사용자와 기업은 해당 기관을 어떻게 신뢰할 수 있나요?

브라우저 상단 표시줄에 자물쇠 아이콘이 표시되는 경우가 있는데, 이것이 무엇을 의미하는지 알고 있나요?

-> SSL 인증서를 의미하는데, SSL 인증서는 무엇인가요?

우리가 흔히 사용하는 공인 인증서의 경우 인증서 안에 어떤 내용이 들어갈까요?

공인 인증서는 A라는 사람이 진짜 A임을 보증해주는 문서입니다.

인증서에는 인증된 기관 CA의 이름(VeriSign)과 개인의 정보와 그리고 개인의 공개키가 들어가 있고, CA에서는 개인의 개인키도 함께 생성해서 전달합니다.

공인 인증서를 사용한다고 할 때 어떤 과정을 거쳐 인증이 될까요?

1. A 사용자는 우선 접속할 은행의 인증서를 먼저 획득
2. A의 인증서와 A의 개인키로 암호화된 데이터를 은행의 공개키로 암호화해서 은행에 전송
3. 은행은 개인키로 복호화한 후, A의 개인키로 암호화된 정보가 A의 인증서 내 공개키로 복호화 된다면 A의 인증서가 맞다는 것을 확인할 수 있다.

공인 인증서에는 CA 기업의 이름, 개인의 공개키가 들어간다고 했는데, 왜 공인 인증서가 유출되면 문제라고 말할까요? 공개키는 유출되어도 상관없는 정보가 아닌가요?

흔히 공인 인증서가 유출되었다는 말은 개인의 private key 가 유출되었다는 의미입니다.

우리나라에서는 보통 인증서와 private key를 같이 저장해두기 때문입니다.

TLS는 어떤 보안 서비스를 제공하고 있고, 각 서비스는 어떻게 보장되고 있나요?

1. 기밀성 : 대칭키 암호화 방식을 사용하게 되면 기밀성을 제공할 수 있습니다.
2. 무결성 : 메시지 인증 코드(MAC)를 통해 메시지 위/변조 여부 확인 가능
3. 인증 : 연결 초기 설정에서 주고 받는 인증서를 통해 신뢰할 수 있는 서버인지 인증가능

TLS에서 인증 서비스와 CA를 통한 인증 서비스는 어떤 차이가 있나요?

TLS는 기밀성, 무결성, 인증 3가지 보안 서비스를 제공하는데 여기서 무결성은 왜 필요한 보안 서비스인가요?

References

• HTTPS의 단점
• HTTP와 HTTPS