프론트 공부/네트워크

SSL (Secure Socket Layer)

캥거루 2021. 5. 13. 01:43

Secure Socket Layer

 

HTTP와 HTTPS

  • HTTP에 대한 설명은 다른 문서를 참고
  • S = Over SSL
  • HTTP에서 보안적인 약점을 보강한 것이 HTTPS
  • 기밀문서 열람이나 감청을 불가능하게 함
  • 개인 정보를 요구하는 사이트의 경우 미적용 시 정보통신망 관련법 위반 (https://www.crosscert.com/symantec/02_3_03.jsp)

SSL Protocol Layer

SSL 도 프로토콜 중의 하나로, TCP, IP 위 application layer에 존재하고, 그 위에 HTTP, Telnet, FTP 등등 의 우리가 아는 기존의 프로토콜이 존재합니다. 여기서 HTTP 가 SSL 이라는 라이브러리를 이용하면 HTTPS (왜 Over SSL 인지 아시겠죠?)

 

 

Version Source Description
SSL v2.0 Vendor Standard (from Netscape Corp.) 첫번째 SSL 프로토콜
SSL v3.0 Expired Internet Draft (from Netscape Corp.) [SSL3] 특정 보안 공격을 막기위한 개정안. non-RSA 암호화 기법을 추가하고, 인증서 체인을 지원함.
TLS v1.0 (RFC 2246, '1999) Proposed Internet Standard (from IETF) [TLS1] Mac layer를 HMAC(Hashed MAC) 으로 업데이트 하기 위한 SSL 3.0 의 개정안. 블록 암호화 기법에 대해 블록 패딩을 지원, 메시지 순서(order)의 표준화와 더 많은 경고 메시지를 지원함.
TLS v1.1 (RFC 4346, '2006) Proposed Internet Standard (from IETF) [TLS11] TLS 1.0의 업데이트. Cipher block chaining (CBC) 공격에 대항하는 보호막 추가.
TLS v1.2 (RFC 5246, '2008) Proposed Internet Standard (from IETF) [TLS12] TLS 1.1의 업데이트. MD5 해쉬기법을 폐기하고 SSL 과 호환 안되게 만들어 놓음. (SSL v2를 더 이상 사용할 수 없게 됨)
TLS v1.3 (RFC 8446, '2018) https://tools.ietf.org/html/rfc8446 TLS 1.2의 업데이트. 핸드셰이크에 '0-RTT' 모드 추가. 핸드셰이크를 최대한 암호화. 키 교환과 암호화 방식을 Cipher Suite 가 아니라 개별적으로 결정함. static RSA 와 Diffie-Hellman Cipher Suite 제거. 자세한 건 아래 참고 링크에서

 

  • 참고로 대부분의 브라우저에서 이미 2020년도 즈음을 기점으로 TLS 1.0, 1.1 버전 지원을 종료한 상태. (유일하게 남은 IE11 도 21년도 봄에 종료한다고 함)

 

📌TLS 는 뜬금없이 뭔가요?

Versions of the SSL protocol

  • SSL과 같은 말로 사용됨.
  • 넷스케이프에 의해서 SSL이 발명되었고, 표준화 기구인 IETF의 관리로 이관되면서 TLS라는 이름으로 변경되었음.
  • 하지만 현재 SSL이라는 이름을 훨씬 많이 사용함

 

SSL이 동작하는 방법 (🎃 TLS 1.2 기반 설명임)

기본적인 방식은 같으므로 1.2 기반으로 설명합니다. 1.3 과의 차이점은 참고자료를 보세요.

 

  • 공개키대칭키를 혼합해서 사용함
  • 왜 ? 성능상의 이점 때문에. - 원래는 클라이언트가 서버에게 공개키로 암호화해서 전송하고, 서버에선 비밀키를 이용해서 복호화하는 방식이 이상적임. 하지만 이 방식은 컴퓨팅 파워를 많이 소모함.
  • 실제 정보는 대칭키로 암호화
  • 복호화 할 때 사용되는 대칭키공개키 방식으로 암호화 (헷갈리지 마세요.)
  • 대칭키는 클라이언트와 서버가 둘 다 갖고 있어야 함

1. Handshake

  1. clientHello : 클라이언트가 서버에 접속한다. 아래는 클라이언트가 제공하는 정보의 목록.
    • 클라이언트 측에서 생성한 랜덤 데이터 (random values)
    • 클라이언트가 지원하는 암호화 방식 (cipher suite)
    • 세션 아이디 (session id)
  2. ServerHello: 서버가 응답함. 아래는 서버가 제공하는 정보의 목록
    • 서버 측에서 생성한 랜덤 데이터
    • 서버가 선택한 클라이언트의 암호화 방식 (cipher suite)
    • 인증서 (Optionally send server certificate and request client certificate)
  3. Certificate Verify
    • 클라이언트는 서버의 인증서가 CA (Certificate Authority)에 의해서 발급된 것인지 확인하기 위해 클라이언트에 내장된 CA list를 확인함.
    • 확인하는 방법은 클라이언트에 내장된 CA의 공개키를 이용하는 것. 이를 이용해 인증서를 복호화함.
    • 복호화에 성공했다면 서버가 생성한 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합하여 pre master secret 키를 생성함. 암호화 기법이 대칭키이기 때문에 이 값은 절대 노출되어서는 안된다.
    • 근데 서버로 전송하려면 서버의 공개키가 필요. 이 공개키는 서버로부터 받은 인증서 내에 있음.
  4. ChangeCipherSpec
    • pre master secret 키를 암호화해서 서버로 전송하면 서버는 자신의 비공개키로 복호화할 수 있다.
    • 이후 서버와 클라이언트는 모두 pre master secret 값을 master secret 값으로 만듦
    • master secret은 session key 생성한다.
    • session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 뒤에 주고받는다.
  5. Finished
    • 서로 끝났음을 알림

2. 세션

  • 세션은 실제로 서버와 클라이언트가 데이터를 주고 받는 과정
  • 정보를 상대방에게 전송하기 전에 session key 이용해 대칭키 방식으로 암호화함.
  • 서로 session key 값을 알고 있기 때문에 암호화 복호화가 자유자재로 가능
  • 이렇게 하는 이유는 위에서 서술했듯 컴퓨팅 파워의 문제. 공개키는 비용이 너무 많이 들고 대칭키는 너무 위험함.

3. 세션의 종료

  • 전송이 끝나면 SSL 통신이 끝났음을 알리고 session key를 폐기함

 

인증서는 사드세요... 제발...🤕

 

이 자물쇠 버튼을 클릭하면 인증서를 확인할 수 있다. (HTTPS 에 한해)

 

ㄷㄷㄷㅈ

 

SSL 인증서의 역할

  1. 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장
  2. SSL 통신에 사용할 공개키를 클라이언트에게 제공

SSL 인증서의 내용

  1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인...)
  2. 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)

CA (Certificate Authority) / Root Certificate

  • 인증서의 역할을 하는 민간 기업들이 존재함.
  • 아무 기업이나 참여할 수 없고 신뢰성이 엄격하게 공인된 기업만 참여할 수 있음. (각 브라우저 벤더들(애플, 구글, 모질라 etc...)이 엄선해서 본인 브라우저에 탑재함)
  • Symantec, Comodo , GoDaddy, GlobalSign... (북미 회사들)

https://www.psmarketresearch.com/market-analysis/certificate-authority-market-outlook

  • 아시아의 참여로 암호화 시장은 더 커질 듯함
  • 사설 인증기관을 사용할 수도 있으나 private 한 사이트 (기관 내부 사이트, 테스팅 용 사이트 등 신뢰할 수 있는 사이트) 에만 적용해야 함.

만약 공인된 인증서가 아니라 사설 인증기관을 사용한다면 브라우저에서 경고 메시지를 출력, private 한 웹사이트에만 적용해야 하고, 조직 내부 사이트나 테스팅용 사이트 정도에 적합한 듯함

 

추가로 알아야 할 사실

  • 브라우저는 CA의 리스트와 각 CA의 공개키를 모두 저장하고 있음.
  • 인증 상의 이유도 있지만, 성능 상의 이유도 있음.
  • CA는 자신의 비공개 키를 이용해서 서버가 제출한 인증서를 암호화하므로 이 키가 절대 유출되어서는 안 됨. 유출로 인해 파산한 사례도 있음.

 

공부하고 나니 드는 생각

가끔 면접 질문에서 '구글에 hello를 검색하면 벌어지는 일들'에 대해 묻는 경우가 왕왕 있다고 한다. 최신 브라우저를 기준으로 한다면 그 과정에서 SSL 얘기는 빼놓을 수 없을 것 같다.


🎪참고 링크

HTTPS와 SSL 기본 설명 (TLS 1.2까지 업데이트되어있음)

HTTPS와 SSL 인증서 - 생활코딩

SSL/TLS Strong Encryption: An Introduction

 

TLS 1.2 → TLS 1.3 설명

Luavis' Dev Story - 알아두면 쓸데없는 신비한 TLS 1.3

 

RSA 암호화 (꺼무 위키)

namu.wiki/w/RSA%20%EC%95%94%ED%98%B8%ED%99%94

 

인증서 체인

www.ibm.com/support/knowledgecenter/ko/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10600_.htm

 

TLS 1.0에서의 HMAC 설명

[암호학] HMAC(Hashed MAC) 개념과 과정