Enochkon's blog

개요

• SSL(Secure Sockets Layer)
• TLS(Transport Layer Security)
• 왜 SSL을 사용해야 하는가?
• 암호화 기법
• SSL 인증서
• SSL Handshake

SSL(Secure Sockets Layer)

• ssl이란 "웹사이트의 ID를 인증하고 암호화된 연결을 생성하는 인터넷 보안 프로토콜"
• Netscape는 개발된 프로토콜로 SSL 1.0은 1995년 개발
  -> 하지만 1.0의 경우 많은 이슈가 있어 공개되지 않았고, 1996년에 2.0부터 공개되기 시작
• 개인정보 보호, 인증, 데이터 무결성을 보장
• 클라이언트와 웹 서버 사이에서 동작

TLS(Transport Layer Security)

• SSL과 거의 동일한 프로토콜
• 특정 회사(Netscape)에 의해 개발된 SSL을 인터넷 표준화 기구인 IETF (Internet Engineering Task Force)에서 표준화
• SSL 3.0 버전을 기반으로 TLS 1.0을 발표

• 윈도우에서 지원되는 SSL과 TLS
  

  

현재는 모든 SSL은 지원하지 않고, TLS만 사용한다.

왜 SSL을 사용해야 하는가?

• ssl같은 보안을 적용하지 않고 그냥 데이터를 주고 받는다면 제 3자가 데이터를 쉽게 탈취할 수 있다.

SSL이 적용되지 않은 경우

• ssl이 적용되지 않으면 위 그림에서 처럼 "High Value Information"라는 문자열이 그대로 전송
• 제 3자가 데이터를 탈취하기 쉽다.

SSL 적용된 경우

• ssl이 적용된 경우에는 데이터가 암호화되어서 보내진다.
• 제 3자가 탈취한다 해도 복호화하기 힘들기 때문에 상대적으로 안전해진다.

암호화 방식

• 사용하는 암호화 방식은 대칭키와 비대칭키를 혼합해서 사용한다.

대칭키 암호화

• 대칭키 암호화 : 인코딩 할 때 사용하는 키와 디코딩 할 때 사용하는 키가 같다. (발송자와 수신자는 같은 비밀키를 알고 있어야 한다.
  ex) DES, Triple-DES, RC2, RC4

• 비밀키의 보안이 제일 중요하다. 대부분의 경우, 인코딩&디코딩 알고리즘은 공개적으로 알려져 있어서 키를 알면 암호를 풀 수 있다.
• 열거 공격(Enumeration Attack) : 가능한 모든 수를 대입해보기 (브루트포스)
  → 이를 방지하기 위해 키값을 늘림. 128비트의 암호키는 2의 128승 의 값이 가능…

      (340282366920938463463374607431768211456가지의 값)

• 대칭키 암호의 단점
  • 발송자와 수신자가 동일한 공유키를 가져야함.
    → 발송자와 수신자의 수 만큼 키가 있어야함, 많은 수의 키를 관리해야함.
  • 공유키가 탈취되면 모든 문서의 암호가 풀릴 수 있음

공개키(비대칭키) 암호화

• 공개키 암호화 : 두 개의 비대칭 키를 사용, 인코딩 키는 공개되어 있고 디코딩 키만이 보안 유지.
  ex) RSA
• 호스트가 인코딩 키를 공개하면, 이 인코딩 키를 사용해서 호스트에게 암호화된 메세지를 보낼 수 있다.
  → 그리고 이 암호화된 메세지는 오직 호스트가 가지고 있는 디코딩 키를 사용해서 볼 수 있다.
  

  

• 대칭키와는 달리 인코딩키를 공유하므로 키의 개수를 줄일 수 있다.

데이터 전달 과정

1. 송신자가 수신자의 공개키를 사용해서 데이터를 암호화 한다.
2. 수신자는 본인만이 가지고 있는 개인키를 사용해서 데이터를 복호화해서 사용한다.

공개키의 단점

• 연산속도가 느리다.

디지털 서명

• 공개키 암호화 방식을 사용해서 구현
• 보내는 이의 개인키를 사용해서 서명을 작성 -> 받는 쪽에서 보낸이의 공개키를 사용해서 복호화

앨리스가 밥에게 보낼 때

1. 앨리스는 밥의 공개키(PK/bob) 을 이용하여 암호화 한다.
2. 앨리스는 앨리스의 개인키(SK/Alice)을 이용하여 서명한다.
3. 밥은 밥의 개인키(SK/bob)을 이용하여 복호화 한다.
4. 밥은 앨리스의 공개키(PK/Alice)을 이용하여 서명을 검증한다.(앨리스가 보낸사항임을 확인함)

앨리스가 밥에게 보낼 때 (해쉬 포함)

1. 앨리스는 밥의 공개키(PK/bob) 을 이용하여 암호화 한다.
2. 앨리스는 문서내용(Hello, Bob)을 해쉬한다.
3. 이 해쉬에 앨리스의 개인키(SK/Alice)를 이용하여 서명한다.
4. 밥은 밥의 개인키(SK/bob)을 이용하여 복호화 한다.
5. 밥은 위의 복호화한 내용을 해쉬한다.
6. 밥은 앨리스에게서 온 서명을 앨리스의 공개키(PK/Alice)을 이용하여 서명을 검증(복호화)한다.
7. 위의 복호화된 값과, 5의 해쉬값이 일치하는지 확인한다. (앨리스가 보낸사항임을 확인함)

간단한 실습

대칭키

# txt 파일 생성
echo "hihihi" > aa.txt

# 1234라는 키를 사용해서 -aes-256-cbc 방법을 사용해서 암호화. 
openssl enc -aes-256-cbc -salt -in aa.txt -out ciphertext.bin -k 1234

# 같은키와 같은 방식으로 복호화
openssl enc -d -aes-256-cbc -in ciphertext.bin -out decrypted.txt -k 1234

비대칭키

# rsa방식으로 1024bit 길이로 키 생성
openssl genrsa -out private.pem 1024;

# private.pem에 대한 공개키 생성
openssl rsa -in private.pem -out public.pem -outform PEM -pubout;

# 공개키를 사용해서 파일 암호화
openssl pkeyutl -encrypt -inkey public.pem -pubin -in aa.txt -out file.ssl;

# 비밀키를 사용한 파일 복호화
openssl pkeyutl -decrypt -inkey private.pem -in file.ssl -out decrypted.txt

SSL 인증서

• SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서
• 보통 CA라고 불리는 공인된 기관에서 유료로 발급
• 인증서 내용
  1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등)
  2. 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)

CA

• CA(Certificate authority) 혹은 Root Certificate 라고도 불림
• 민간기업 중 엄격한 심사를 통해서 선정된 SSL 인증서 발급 기업
• 이 CA는 기본적으로 브라우저에 내장되어 있다.

• 맥의 경우 키체인에서 CA 인증서들을 확인할 수 있다.

SSL 인증서가 서비스를 보증하는 방법

1. 웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공
2. 브라우저는 이 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지를 확인
3. 확인 결과 서버를 통해서 다운받은 인증서가 내장된 CA 리스트에 포함되어 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화
   => 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미
   => 즉 안전하다.

SSL Handshake

• 파란 부분은 tcp handshake
• 노란 부분이 ssl handshake

1. ClientHello
   • client측에서 서버에 연결을 요청한다. (인사?)
   • session id, ssl protocol version, cipher suite 목록 등의 정보를 담아서 전송
2. ServerHello & Certificate, ServerHelloDone
   ServerHello
   • 1번에서 클라이언트에서 받은 인사(Client Hello 패킷)에 대해 서버가 응답
   • ssl protocol version, client suite중 하나 선택해서 응답
     Certificate, ServerHelloDone
   • Server 의 SSL 인증서 내용을 클라이언트에게 전송
3. client 에서 server 의 SSL 인증서 검증
   • 서버에서 받은 인증서 정보를 가지고 유효한 인증서인지 검증한다.
4. Client Key Exchange
   • 서버의 인증서 검증을 마친 후, 클라이언트는 서버와 통신하기 위한 대칭키를 생성한다.
   • 이 생성한 대칭키를 서버의 공개키를 사용해서 암호화 해서 서버에게 전송한다.
5. Server / Client SSL Handshake Finished
   • 서버가 암호화된 대칭키를 받아서 복호화에 성공하면 연결이 끝난다.

기타

무료 인증서 발급 사이트 목록

1. Let’s Encrypt : https://letsencrypt.org/
2. Comodo Free SSL : https://www.gogetssl.com/domain-validation/comodo-free-ssl/
3. CloudFlare One-Click SSL : https://www.cloudflare.com/ssl/
4. AWS Certificate Manager : https://aws.amazon.com/ko/certificate-manager/

Reference

https://hstory0208.tistory.com/entry/SSL-%EC%9D%B4%EB%9E%80-TLS-%EC%9D%B4%EB%9E%80
https://captcha.tistory.com/51
https://support.cafe24.com/hc/ko/articles/8469947344409-SSL%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94-
https://velog.io/@yjw8459/%EC%9B%B9-%EC%82%AC%EC%9D%B4%ED%8A%B8-%EB%B3%B4%EC%95%88-SSL%EC%9D%B4%EB%9E%80
https://12bme.tistory.com/80
https://arc.net/l/quote/gqzfvkyb