개요
- 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 - 호스트가 인코딩 키를 공개하면, 이 인코딩 키를 사용해서 호스트에게 암호화된 메세지를 보낼 수 있다.
→ 그리고 이 암호화된 메세지는 오직 호스트가 가지고 있는 디코딩 키를 사용해서 볼 수 있다.
- 대칭키와는 달리 인코딩키를 공유하므로 키의 개수를 줄일 수 있다.
데이터 전달 과정
- 송신자가 수신자의 공개키를 사용해서 데이터를 암호화 한다.
- 수신자는 본인만이 가지고 있는 개인키를 사용해서 데이터를 복호화해서 사용한다.
공개키의 단점
- 연산속도가 느리다.
디지털 서명
- 공개키 암호화 방식을 사용해서 구현
- 보내는 이의 개인키를 사용해서 서명을 작성 -> 받는 쪽에서 보낸이의 공개키를 사용해서 복호화
앨리스가 밥에게 보낼 때
- 앨리스는 밥의 공개키(PK/bob) 을 이용하여 암호화 한다.
- 앨리스는 앨리스의 개인키(SK/Alice)을 이용하여 서명한다.
- 밥은 밥의 개인키(SK/bob)을 이용하여 복호화 한다.
- 밥은 앨리스의 공개키(PK/Alice)을 이용하여 서명을 검증한다.(앨리스가 보낸사항임을 확인함)
앨리스가 밥에게 보낼 때 (해쉬 포함)
- 앨리스는 밥의 공개키(PK/bob) 을 이용하여 암호화 한다.
- 앨리스는 문서내용(Hello, Bob)을 해쉬한다.
- 이 해쉬에 앨리스의 개인키(SK/Alice)를 이용하여 서명한다.
- 밥은 밥의 개인키(SK/bob)을 이용하여 복호화 한다.
- 밥은 위의 복호화한 내용을 해쉬한다.
- 밥은 앨리스에게서 온 서명을 앨리스의 공개키(PK/Alice)을 이용하여 서명을 검증(복호화)한다.
- 위의 복호화된 값과, 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라고 불리는 공인된 기관에서 유료로 발급
- 인증서 내용
- 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등)
- 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)
CA
- CA(Certificate authority) 혹은 Root Certificate 라고도 불림
- 민간기업 중 엄격한 심사를 통해서 선정된 SSL 인증서 발급 기업
- 이 CA는 기본적으로 브라우저에 내장되어 있다.
- 맥의 경우 키체인에서 CA 인증서들을 확인할 수 있다.
SSL 인증서가 서비스를 보증하는 방법
- 웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공
- 브라우저는 이 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지를 확인
- 확인 결과 서버를 통해서 다운받은 인증서가 내장된 CA 리스트에 포함되어 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화
=> 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미
=> 즉 안전하다.
SSL Handshake
- 파란 부분은 tcp handshake
- 노란 부분이 ssl handshake
- ClientHello
- client측에서 서버에 연결을 요청한다. (인사?)
- session id, ssl protocol version, cipher suite 목록 등의 정보를 담아서 전송
- ServerHello & Certificate, ServerHelloDone
ServerHello- 1번에서 클라이언트에서 받은 인사(Client Hello 패킷)에 대해 서버가 응답
- ssl protocol version, client suite중 하나 선택해서 응답
Certificate, ServerHelloDone - Server 의 SSL 인증서 내용을 클라이언트에게 전송
- client 에서 server 의 SSL 인증서 검증
- 서버에서 받은 인증서 정보를 가지고 유효한 인증서인지 검증한다.
- Client Key Exchange
- 서버의 인증서 검증을 마친 후, 클라이언트는 서버와 통신하기 위한 대칭키를 생성한다.
- 이 생성한 대칭키를 서버의 공개키를 사용해서 암호화 해서 서버에게 전송한다.
- 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
'CS' 카테고리의 다른 글
흐름제어(flow control)와 혼잡제어(congestion control) (0) | 2024.01.19 |
---|---|
HTTPS와 SSL Handshake (0) | 2024.01.13 |