SSL (Secure Socket Layer)

I. 안전한 데이터 통신 위한, SSL

가. SSL(Secure Socket Layer)의 개념

• 클라이언트와 서버 간 통신하는 데이터를 안전하게 보호하기 위해 사용자 인증 및 비밀키 암호화를 사용하는 보안 프로토콜
• 99년 SSLv3 보완 TLS(Transport Layer Security)로, RFC2246 표준화
• 현재: SSLv3지원 중단 추세, TLS최신 버전: TLS1.2 (2015.04.19 기준)

나. SSL 프로토콜 내부 구조

II. 일반 HTTP의 취약점

가. http와 https 비교 개념도

나. http 취약점

III. SSL의 특징

특징	개념도	설명
포트		– 보안 포트 – 443 port 사용
URL 표기		– 주소표시줄 녹색 – https:// 시작 – 사용자 인지
보안성 강화		– SSL/TLS 암호화 – 보안소켓 레이어 – 데이터 무결성
SSL 핸드쉐이크		– 상호 신원인증 – 임시 세션키
인증서 사용		– 인증기관 통해 SSL 인증서 발급 – X.509 인증기반
비용		– Keep-Alive 이용 – 세션 유지 시 암호화 비용 절약
속도		– SPDY, HTTP/2 이용 시 다중화 – TCP 연결 빠른 속도

IV. SSL 프로토콜 구조의 이해

가. Handshake Protocol

• 클라이언트와 서버가 SSL 통신을 하기 전 수행되며, SSL 프로토콜 버전과 암호 알고리즘(키 교환, 비밀키, MAC)을 설정, 인증 및 키 교환하여 비밀키 공유

– Handshake Protocol 과정

– Abbreviate Handshake 과정

나. Alert Protocol

• 통신 중 오류 발생을 알려주며, 2Byte 단일 메시지로 구성
• Warning(Value=1), Fatal(Value=2) 레벨, Fatal 시 재 접속 불가

다. Change Cipher Protocol

• Handshake 과정에서 설정된 Pending State를 Current State로 바꿔주는 프로토콜로 1Byte 단일 메시지
• 송신측은 Pending Write State를 Current Write State에 복사
• 수신측은 Pending Read State를 Current Read State에 복사

라. Record Protocol

• Application Data 포함, Handshake 이후 전송되는 모든 데이터에 대해 MAC을 계산, 암호화하여 전송 역할, 기밀성, 무결성 제공
• 송신 시 Fragmentation → Compression / MAC → Encryption
• 수신 시 Decryption → Decompression / MAC → Reassemble

V. SSL의 Session과 Connection

가. Session과 Connection의 개념

• SSL은 Session과 Connection 별로 상태를 유지하는 Stateful 프로토콜이며, 한 Session 내 여러 Connection이 존재, 실제 통신은 Connection에서 수행
• Session State: Full Handshake 프로토콜에 의해 설정되며, Session에서 사용할 알고리즘과 Master Secret이 포함. 같은 Session 내 모든 Connection 들이 공유하는 State
• Connection State: Session State의 알고리즘에 대한 비밀키, MAC Secret, 블록암호화의 IV(Initial Vector), Sequence Number 등을 포함하여 Full Handshake에 의해 Session이 생성되면, Abbreviate Handshake를 사용하여 Session State를 공유하면서 Connection State만 재생성 가능

나. State

• Current State: Record Layer에서 실제 데이터가 처리 사용 State
• Write State: 상대방에게 데이터를 보낼 때 사용하는 State
• Read State: 상대방이 보낸 데이터를 읽기 위한 State

다. SSL Handshake 과정 및 상태표

① Full Handshake 프로토콜이 시작되면 모든 State는 null상태로 초기화
② 새로운 Session을 생성하는 경우, 서버와 클라이언트가 사용할 Cipher Suite를 동의, 난수 교환하여 pre-master secret, master secret과 키 블록들 생성하여 Pending State로 갱신
③ Session State를 재사용하는 경우, Abbreviate Handshake 프로토콜로 원래의 Session State는 그대로 유지하고 서버와 클라이언트가 새로 교환한 난수로 새로운 키 블록을 생성하여 Pending State로 갱신
(이때, Client는 Server에서 보낸 SSL 인증서 내 공개키로 비밀키를 암호화하여 Server에 전달하고, Server에서는 개인키를 이용하여 복호화한 비밀키를 저장. Client/Server는 안전하게 비밀키를 공유)
④ Pending Write State는 “Change Cipher Spec” 메시지를 상대방에게 보냄과 동시에 Current Write State로 변경
⑤ Pending Read State는 “Change Cipher Spec” 메시지를 상대방으로부터 받음과 동시에 Current Read State로 변경
⑥ 바뀐 Pending State는 null 상태로 초기화되고, 새로 설정된 보안 파라미터로 보호된 메시지를 보내기 전에 반드시 Change Cipher Spec메시지 전송

VI. SSL 문제점 및 해결방안

가. SSL의 문제점

• SSL 사용에 따른 서버의 성능저하: 서명 생성과 검증 및 비밀키 키 교환에 필요한 수학적 연산 과정은 많은 계산능력을 필요로 함
• 서버의 비밀키 보안 문제: 서버의 비밀키는 하드 드라이브에 저장되므로 해킹에 의한 보안상의 취약점 존재
• 트래픽 관리 상의 문제: SSL은 패킷을 암호화하기 때문에 URL, cookies, application header에 따른 라우팅을 결정하는 트래픽 관리 장치(L4 Switch, L7 Switch)들이 기능 발휘 어려움

나. 해결 방안

• SSL 가속기: 서버 성능 향상, 인증서 관리, 트래픽 관리 기능
• CDN(Contents Delivery Network) 서비스 사용

 
 
※ SSL에서 동작하는 응용 프로그램 할당 포트 번호