보안기사 - 전송계층 보안 (SSL/TLS)

SSL/TLS

---

SSL(Secure Socket Layer)은 1994년 Netscape사의 웹 브라우저를 위한 보안 프로토콜로 처음 제안되어 1996년 SSL3.0 버전까지 발표
1999년 IETF에서 SSL3.0을 기반으로 표준화시킨 TLS1.0 버전을 발표, 현재 TLS1.2 버전까지 널리 사용

SSL/TLS는 클라이언트/서버 환경에서 TCP 기반의 Application에 대한 종단간 보안서비스를 제공하기 위해 만들어진 전송계층 보안 프로토콜
- 전송계층(TCP)과 어플리케이션 계층 사이에서 동작, 다양한 TCP 기반의 어플리케이션 프로토콜에 보안서비스를 제공
- 각 어플리케이션 프로토콜이 SSL을 이용할 경우 이를 구분하기 위해 고유한 well-known 포트를 할당
    : https(443/tcp), smtps(465/tcp), ftps(990/tcp), telnets(992/tcp)

보안서비스 제공

1. 기밀성 (Confidentiality)
   대칭 암호를 이용한 송수신 메시지 암호화를 통해 기밀성 제공
   
   
2. 무결성 (Integrity)
   메시지 인증 코드(MAC)를 통해 송수신 메시지의 위변조 여부를 확인할 수 있는 무결성을 제공
   
   
3. 인증 (Authentication)
   공개키 인증서를 이용한 서버/클라이언트 간 상호 인증을 수행

SSL/TLS 프로토콜 구조

---

SSL/TLS는 크게 2계층으로 이루어진 프로토콜
- 상위계층 : Handshake, Change Cipher Spec, Alert, Application Data 프로토콜로 구성
- 하위계층 : Record 프로토콜

• Handshake 프로토콜
  종단 간 보안 파라미터를 협상 (세션 상태정보)
• Change Cipher Spec 프로토콜
  종단 간 협상된 보안 파라미터를 이후부터 적용/변경함을 알림
• Alert 프로토콜
  SSL/TLS 통신 과정에서 발생하는 오류를 통보
• Application Data 프로토콜
  Application 계층의 데이터를 전달
• Record 프로토콜
  적용/변경된 보안 파라미터를 이용해 실제 암호화/복호화, 무결성 보호, 압축/압축해제 등의 기능 제공

상태 유지(Stateful) 프로토콜

• 세션과 연결 기반의 상태 유지 프로토콜
  완전 협상(full handshake, 13단계)을 통해 세션을 생성하고, 이 세션정보를 공유하는 다수의 연결을 단축협상(6단계)을 통해 생성
  (매 연결마다 새로운 세션을 생성하고 보안파라미터를 협상하는 것이 비효율적이므로 협상 부담을 줄인 것)
  
  
• 세션 상태 정보
  양 종단 간에 완전 협상을 통해 생성되는 상태정보로 세션이 유지되는 동안 지속적으로 다수의 연결에 의해 사용되는 보안 파라미터 정보가 관리됨

  필드	설명
  session ID	둘 사이의 세션 식별자 (32bytes)
  peer certificate	상대방 인증서 (X.509v3)
  cipher spec (암호 명세)	대칭 암호 알고리즘, 키 길이, 블록 암호 모드 등 HMAC용 해시 알고리즘
  compression method	압축 방식 (현재는 null만 정의)
  master secret	키 블럭을 생성하기 위해 서버와 클라이언트가 공유하는 48바이트 비밀값 완전 협상을 통해 생성한 premaster secret, server random, client random을 조합/해시하여 master secret을 생성 server random, client random은 master secret을 생성하기 위한 salt 역할 수행
  is resumable	현재 세션이 재사용될 수 있는지 여부 플래그 재사용된다 = 여러 연결에 의해 다시 사용될 수 있는가

• SSL/TLS 연결 상태 정보
  통신이 이루어지는(데이터 송수신) 단위로 단축 협상을 통해 생성
  세션 상태를 공유하며 통신을 수행

  필드	설명
  server/client random	단축 협상을 통해 서버/클라이언트가 생성한 32바이트 난수값 세션에 저장된 master secret와 단축 협상을 통해 생성된 client random, server random을 조합/해시하여 Key Block을 생성한 후 이를 이용해 다양한 키를 만들어냄 server random, client random은 master secret을 생성하기 위한 salt 역할 수행
  server/client write key	서버/클라이언트가 암호화에 사용하는 비밀키
  server/client write MAC secret	서버/클라이언트가 메시지 인증 코드(MAC) 생성 시 사용하는 인증키
  server/client write IV	서버/클라이언트가 블록 암호 모드에 사용하는 IV(Initialize Vector)
  sequence number	전송 메시지 순번

• 세션 상태정보와 연결 상태정보를 이용한 키 생성 과정
  완전 협상을 통해 주고 받은 Premaster Secret, Client Random, Server Random을 조합해 해시한 결과로 Master Secret 생성 Master Secret은 다수 연결이 이용할 수 있도록 세션상태에 저장 단축 협상을 통해 주고 받은 Client Random, Server Random과 세션에 저장된 Master Secret을 조합해 해시한 결과로 Key Block 생성 Key Block으로부터 서버/클라이언트 각각의 암호용 비밀키, MAC용 인증키, 블럭 암호 모드용 IV를 계산

완전 협상 과정 (Handshake 프로토콜)

1. Client Hello 메시지 (client -> server)
   클라이언트가 지원 가능한 SSL/TLS 버전, 암호 도구 목록(cipher suites), 압축 방식 등을 서버에 전달하는 메시지
   • client random
     클라이언트가 생성하는 32바이트 난수값으로 'master secret'및 'key block' 생성 시 salt 역할 수행
   • session ID
     서버 세션을 식별하기 위한 ID로 클라이언트가 처음 세션을 생성할 때는(완전 협상) 빈값을 전달하고,
     이미 생성된 세션을 재사용할 때는(단축 협상) 세션 ID를 담아 전달
   • 암호 도구 목록 (cipher suites)
     클라이언트에서 지원 가능한 cipher suite 정보를 담아서 전송
     키 교환 및 인증 알고리즘, 암호 명세(cipher spec)로 구성
     (형식) SSL/TLS_(키교환및인증알고리즘)_WITH_(cipher_spec)
     cipher spec은 대칭 암호 알고리즘, 암호키 길이, 블럭 암호 모드, HMAC용 해시 알고리즘 등으로 구성
     TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA256
2. Server Hello 메시지 (server -> client)
   사용할 SSL/TLS 버전, 암호 도구(cipher suite), 압축 방식 등을 클라이언트에 전달하는 메시지
   • server random
     서버가 생성하는 32바이트 난수값으로 'master secret'및 'key block' 생성 시 salt 역할 수행
   • session ID
     새롭게 생성하거나 존재하는 세션 ID 정보
3. Server Certificate* 메시지 (server -> client)
   필요시 서버 인증서 목록(서버 인증서 및 인증서에 서명한 인증기관들의 인증서 목록)을 클라이언트에 전달하는 메시지
   클라이언트는 이걸 검증해서 올바른 상대방인지 인증 가능
   
   
4. Server Key Exchange* 메시지 (server -> client)
   필요시 키 교환에 필요한 정보를 전달하는 메시지
   키 교환 알고리즘으로 Ephemeral Diffie-Hellman(DHE, ECDHE)을 사용한다면 공개 Diffie-Hellman 매개변수(p, g, 서버 공개키)를 서명 알고리즘으로 서명해 서명값과 함께 전달
   (RSA 사용시에는 전달X, DH 사용시!)
   
   
5. Certificate Request* 메시지 (server -> client)
   필요시 클라이언트 인증을 위한 인증서를 요청하는 메시지
   요청 시에는 서버 측에서 인증 가능한 인증기관 목록을 제공
   
   
6. Server Hello Done 메시지 (server -> client)
   Server Hello 과정 종료를 알리는 메시지
   
   
7. Client Certificate* 메시지 (client -> server)
   필요시(서버의 Certificate Request 메시지) 클라이언트 인증서 목록을 전달하는 메시지
   
   
8. Client Key Exchange 메시지 (client -> server)
   키 교환에 필요한 Premaster Secret을 생성하여 서버에 전달하는 메시지
   키 교환 알고리즘에 따라 생성 방식이 다름
   • RSA : Premaster Secret 생성 후 수신한 서버 인증서의 공개키를 이용해 암호화 전송
   • Diffie-Hellman : 클라이언트 DH 공개키를 생성해 서버에 전달, 클라이언트와 서버는 각각 DH 연산을 통해 공통의 Premaster Secret을 생성
9. Certificate Verify* 메시지 (client -> server)
   필요시(서버의 Certificate Request 메시지) 클라이언트가 보낸 인증서에 대한 개인키를 클라이언트가 가지고 있음을 증명하는 메시지
   지금까지 handshake 과정에서 주고받은 메시지와 master secret을 조합한 해시값에 클라이언트 개인키로 서명해 전달
   
   
10. [Change Cipher Spec] 메시지 (client -> server)
    협상한 cipher spec을 이후부터 적용/변경함을 알리는 메시지
    
    
11. Finished 메시지 (client -> server)
    협상 완료를 서버에 알리는 메시지
    
    
12. [Change Cipher Spec] 메시지 (server -> client)
    협상한 cipher spec을 이후부터 적용/변경함을 알리는 메시지
    
    
13. Finished 메시지 (server -> client)
    협상 완료를 클라이언트에 알리는 메시지

* Diffie-Hellman 키교환 알고리즘

* SSL/TLS에서의 Diffie-Hellman 키교환 유형

1. Ephemeral Diffie-Hellman (임시 DH)
   매 협상시마다 새로운 DH 개인키(임의의 정수값)을 생성하고 공개 DH 매개변수에 대한 서명(cipher suite의 인증/서명 알고리즘 이용)을 통해 인증 수행
2. Anonymous Diffie-HEllman (익명 DH)
   임시 DH와 동일하게 새로운 DH 개인키를 생성하지만 매개변수에 대한 인증을 수행하지 않기 때문에 중간자공격에 취약하므로 해당 방식의 cipher suite는 사용X 권장
   (주로, RSH, DHE, ECDHE 등이 cipher suite에서 볼 수 있음)

단축 협상(Abbreviated Handshake) 과정

1. Client Hello 메시지 (client -> server)
   사용할 session id와 client random 전달
   
   
2. Server Hello 메시지 (server -> client)
   server random 전달

* 서버에 해당 session id 없으면 ?
서버는 새로 session id 발급하고, 완전협상과정 다시 시작

Record 프로토콜 과정

협상된 알고리즘을 이용해 메시지를 압축/압축해제, 무결성 검증, 암호화/복호화하여 송수신하는 기능을 수행

1. 단편화(Fragmentation)
   어플리케이션 데이터를 일정 크기로 단편화
   
   
2. 압축(Compression) 후 MAC 추가
   단편화된 데이터를 협상을 통해 적용된 압축 알고리즘으로 압축한 후 MAC값을 계산하여 추가
   
   
3. 암호화(Encryption)
   압축된 데이터와 MAC 값을 협상을 통해 적용된 암호 알고리즘으로 암호화
   
   
4. Record 헤더 추가
   암호화된 데이터에 Record 헤더를 추가해 전송

SSL/TLS와 완전 순방향 비밀성(PFS: Perfect Forward Secrecy)

• SSL/TLS 통신의 서버 개인키 노출 시 문제점
  서버 공개키와 개인키를 이용해 키 교환을 수행할 경우(RSA 방식), 공격자는 중간자 공격을 통해 트래픽을 가로채고 서버 개인키를 이용해 세션키/비밀키 및 송수신 데이터를 복호화 가능
  희생자는 유출된 서버 인증서를 폐기해도(CRL, OCSP 등) 유출된 서버 개인키로 보호되는 이전 트래픽 정보를 공격자가 보관하고 있다면 이들 모두 복호화되는 문제점 존재
  이를 해결하기 위해 등장한 암호학적 성질 -> (완전) 순방향 비밀성
  
  
• 완전 순방향 비밀성(PFS)
  서버 개인키가 노출되어도 이전 트래픽 정보의 기밀성은 그대로 유지되는(과거의 세션키가 노출되지 않는) 암호학적 성질
  클라이언트 서버 간에 키 교환에 사용되는 서버 개인키가 노출되어도 이전 트래픽의 세션키/비밀키 기밀성은 그대로 유지되어 통신 내용을 알 수 없는 암호학적 성질
  
  
• SSL/TLS의 PFS 지원
  키 교환 시마다 클라이언트/서버가 새로운 DH개인키를 생성하는 임시 디피-헬만 키 교환을 통해 클라이언트/서버간 Premaster Secret을 생성하고 서버 개인키는 서버 DH 파라미터를 인증하는 목적으로만 사용하믕로써 서버 개인키가 노출되어도 통신 내용을 알 수 없는 완전 순방향 비밀성 지원
  
  
• 완전 순방향 비밀성만 적용하기 어려운 이유
  DH 키 교환의 경우 RSA에 비해 속도가 느리다. -> 성능상 이유로 DHE(Ephemeral), ECCDHE(Elliptic Curve DHE) 관련 cipher suite을 비활성화하는 경우가 있다
  모든 웹브라우저에서 다양한 DHE, ECDHE 관련 cipher suite을 모두 지원하지 않기 때문에 브라우저 호환을 위해 RSA 방식의 키 교환을 함께 사용하는 경우가 있다