제 14 장 SSL/TLS 안전한 통신을 위해

14.1 주요 내용 SSL(Secure Socket Layer ) TLS(Transport Layer Security) 전자 상거래가 활발해지면서 웹 보안이 매우

중요한 주제가 되고 있다 . 웹 서 버 상 의 자 료 를 보 호 하 고 웹 서 버 에

접속하는 사용자의 안전한 상거래를 위해서 필요한 여러 보안 조치들이 개발되었다 .

그 중의 한 가지가 SSL/TLS 이다 .

14.2 웹 보안 암호 알고리즘을 조정하는 정보 조각 평문을 암호문으로 전환 암호문을 복호화하는 역할 디지털 서명 구조 키를 이용한 해시 함수 인증

14.2.1 웹 보안의 필요성 WWW 는 인 터 넷 과 TCP/IP 인 트 라 넷 상 에 서 운 영 되 는 기 본 적 인 클 라 이 언 트 / 서 버 응용프로그램이다 .

웹보안의 문제점들 인터넷은 양 방향 통신이라는 점에 유의해야 한다 .

사실 웹은 인터넷을 통한 웹 서버 공격에 취약하다 . 전자 상거래에서 웹의 역할이 점점 더 확대되고 있다 . 복잡한 웹 브라우저 소프트웨어 속에는 우리가 알 수 없는 숨겨진 많은 보안적 결함들이 있을 수 있다 .

웹보안의 문제점들 웹 관련 기술이 수시로 업그레이드되고 있지만 보안에 대한 검증절차가 불분명하다 . 웹 서버가 기업이나 기관의 전체 컴퓨터 시스템에 침입하는 도구로 사용되기도 한다 . 일반 사용자들이 어려운 웹 보안 관련 기술을 모르고도 안전하게 사용할 수 있는 환경이 제공되어야 한다 .

14.2.2 웹 보안 위협 웹을 사용할 때 나타날 수 있는 여러 보안 위협의 유 형 을 소 극 적 공 격 과 적 극 적 공 격 이 란 개 념 을 이용하여 분류해보자

웹에 대한 위협

14.2.3 웹 트래픽 보안 방법 웹의 응용 범위나 TCP/IP 프로토콜 계층에서

웹의 상대적 위치에 따른 웹 보안 방법 IPSec 응용프로그램별로 보안을 제공하는 방법

응용계층과 전송계층 사이에서 보안조치를 취하는 웹 보안 방법 전송계층의 프로토콜인 TCP 바로 위에서 보안을

구현하는 것 . 이 방법의 가장 좋은 예는 SSL/TLS 이다

14.3 SSL/TLS 란 언제나처럼 앨리스와 밥을 등장시켜 SSL/TLS 가

사용되는 시나리오를 생각해보자 .

14.3.1 온라인 상거래 신용카드 번호를 입력하는 페이지의 URL 은

http:// 가 아니고 https:// 라는 문자열로 시작되고 있다 웹 브라우저 하단에 자물쇠 마크가 작게 표시되어 정말로 안전하게 보인다 웹 브라우저의 자물쇠 마크는 SSL/TLS 에 의해 통신이 지켜지고 있다는 증거로서 표시되고 있는 것이다

14.3.2 클라이언트와 서버 우선 앨리스와 밥 서점 사이의 통신을 이용해서

설명해보자

앨리스의 웹 브라우저 ( 클라이언트 ) 와 밥 서점의 웹 서버 ( 서버 ) 가 HTTP 로 통신을 수행한다

SSL/TLS 를 사용하지 않고 신용카드 번호를 보냈을 경우

14.3.3 SSL/TLS 상의 HTTP 통신 내용을 암호화해 주는 프로토콜로서 SSL(S

ecure Socket Layer) 혹은 TLS(Transport Layer Security) 를 이용한다 .

그리고 SSL/TLS 상에 HTTP 를 올리는 것이다 이것은 프로토콜의 이중 구조이다 . 이것에 의해 HTTP 의 통신 ( 요청과 응답 ) 은

암호화되어 도청을 방지할 수 있다 . SSL/TLS 로 통신을 수행할 때의 URL 은 http://

가 아니고 https:// 로 시작된다 .

HTTP 를 SSL/TLS 상에 올려서 요청과 응답을 암호화한다

14.3.4 SSL/TLS 의 역할 앨리스는 웹 브라우저를 사용해서 밥 서점에

신용카드 번호를 보내고 싶은 것이다 . 여기에는 풀지 않으면 안 되는 문제가 몇 개 있다 .

(1) 앨리스가 송신하는 신용카드 번호와 주소를 「도청」당하는 일 없이 밥 서점에 보내고 싶다 .

(2) 앨리스가 송신하는 신용카드 번호와 주소를 「수정」당하는 일 없이 밥 서점에 보내고 싶다 .

(3) 통신 상대의 웹 서버가 「진짜 밥 서점」이라는 것을 확인하고 싶다 .

14.3.5 SSL/TLS 와 다른 프로토콜 SSL/TLS 상에는 HTTP 뿐만 아니라 , 다른

프로토콜도 올릴 수 있다 . 예를 들면 메일을 전송하기 위한 SMTP(Simple M

ail Transfer Protocol) 나 , 메일을 수신하기 위한 POP3(Post Office Protocol) 와 같은 프로토콜을 SSL/TLS 상에 올릴 수도 있다 .

이 경우에 SSL/TLS 는 송수신하는 메일을 지키고 있는 셈이다 .

HTTP, SMTP, POP3 을 SSL/TLS 상에 올린다

14.3.6 암호 스위트 SSL/TLS 에서 사용하는 대칭 암호 , 공개 키 암

호 , 디지털 서명 , 일방향 해시 함수 등은 부품과 같이 교환할 수 있다

사용하고 있던 암호 기술에 결함이 발견되었을 때는 그 부분을 교체할 수 있는 모듈화된 프레임워크이다

암호 기술의 「추천 세트」가 SSL/TLS 로 규정되어 있다 . 이 추천 세트를 암호 스위트 (cipher suite) 라고 한다 .

14.3.7 SSL 과 TLS 의 차이 SSL 과 TLS 는 골자는 같지만 미묘한 차이가

있다 SSL(Secure Socket Layer)

1994 년 Netscape 사에 의해 만들어졌고 웹 브라우저인 Netscape Navigator 에 내장되었다 .

그 후 많은 웹 브라우저에서 사용되어 사실상의 업계의 표준이 되었다 .

SSL 은 1995 년에 Version 3.0 이 되었다 .

TLS(Transport Layer Security) SSL 3.0 을 기초로 해서 IETF 가 만든

프로토콜이다 . 1999 년에 RFC2246 으로서 발표된 TLS 1.0 은

SSL 3.1 에 해당되는 것이다 .

14.4 SSL/TLS 를 사용한 통신 SSL/TLS 를 사용한 통신 절차를 소개하겠다 .

14.4.1 계층화된 프로토콜 구성

TLS 레코드 프로토콜 암호화 처리

TLS 핸드쉐이크 프로토콜 암호화 이외의 다양한 처리를 수행 4 개의 서브 프로토콜로 나누어진다

TLS 프로토콜 계층

(1) TLS 레코드 프로토콜 TLS 핸드쉐이크 프로토콜 밑에 있으며 , 대칭

암호를 사용해서 메시지를 암호화하고 통신하는 부분이다 .

TLS 레코드 프로토콜에서는 대칭 암호와 메시지 인증 코드를 이용하지만 , 알고리즘과 공유 키는 핸드쉐이크 프로토콜을 사용해서 서버와 클라이언트가 상담하여 결정한다 .

(2) TLS 핸드쉐이크 프로토콜 ( 가 ) 핸드쉐이크 프로토콜( 나 ) 암호 사양 변경 프로토콜( 다 ) 경고 프로토콜( 라 ) 애플리케이션 데이터 프로토콜

( 가 ) 핸드쉐이크 프로토콜 클라이언트와 서버가 암호 통신에 사용할 알고리즘과 공유 키를 결정하기 위한 것이다 . 인증서를 이용한 인증도 여기에서 수행한다 . 4 개의 서브 프로토콜 중 가장 복잡

( 나 ) 암호 사양 변경 프로토콜 TLS 핸드쉐이크 프로토콜의 일부로 암호 방법을 변경하는 신호를 통신 상대에게 전하기 위한 것이다

( 다 ) 경고 프로토콜 뭔가 에러가 발생했다는 것을 통신 상대에게 전하기 위한 것이다 .

( 라 ) 애플리케이션 데이터 프로토콜 TLS 상에 올라 있는 애플리케이션의 데이터를 통신 상대에게 전하는 프로토콜이다 .

14.4.2 TLS 레코드 프로토콜 TLS 레코드 프로토콜로 수행하는 것은 메시지의 압축 , 암호화 , 그리고 데이터의 인증이다 .

TLS 레코트 프로토콜의 처리

14.4.3 핸드쉐이크 프로토콜 핸드쉐이크 프로토콜은 TLS 핸드쉐이크

프로토콜의 일부로 공유 키를 생성하고 인증서를 교환하기 위한 것이다 .

공유 키를 생성하는 것은 암호 통신을 행하기 위한 것이고 , 인증서를 교환하는 것은 서로 상대를 인증하기 위한 것이다 .

절차 (1) ClientHello( 클라이언트→서버 )

클라이언트가 서버에게 ClientHello 라는 메시지를 보낸다 .

보내지는 정보 사용할 수 있는 버전 번호 현재 시각 클라이언트 랜덤 세션 ID 사용할 수 있는 암호 스위트 목록 사용할 수 있는 압축 방법 목록

(2) ServerHello( 클라이언트←서버 ) 클라이언트로부터 받은 ClientHello 에 대해 , 서버는

ServerHello 라고 하는 메시지를 보낸다 . 추가되는 정보

사용하는 버전 번호 현재 시각 서버 랜덤 세션 ID 사용하는 암호 스위트 사용하는 압축 방법

(3) Certificate( 클라이언트←서버 ) 서버가 Certificate 메시지를 보낸다 . 추가되는 메시지

인증서 목록

(4) ServerKeyExchange( 클라이언트←서버 ) 서버가 ServerKeyExchange 메시지를 보낸다 .

(5) CertificateRequest( 클라이언트←서버 ) 서버가 CertificateRequest 메시지를 보낸다 . 보내지는 정보

서버가 이해할 수 있는 인증서 타입 목록 서버가 이해할 수 있는 인증기관 이름 목록

(6) ServerHelloDone( 클라이언트←서버 ) 서버가 ServerHelloDone 메시지를 보낸다 .

(7) Certificate( 클라이언트→서버 ) 클라이언트가 Certificate 메시지를 보낸다 .

(8) ClientKeyExchange( 클라이언트→서버 ) 클라이언트가 ClientKeyExchange 메시지를 보낸다 . 암호화한 사전 마스터 비밀이 보내진다 .

사전 마스터 비밀이란 클라이언트가 만든 난수 후에 마스터 비밀 (Master Secret) 을 만들기 위한 종자 이 값은 서버의 공개 키로 암호화해서 서버에게 보낸다 사전 마스터 비밀을 사용해서 서버와 클라이언트는

공통의 마스터 비밀을 계산한다 . 그리고 마스터 비밀을 기초로 해서 다음과 같은 비트 열

( 키 소재 ) 을 만든다 대칭 암호 키 메시지 인증 코드 키 대칭 암호의 CBC 모드에서 이용하는 초기화 벡터 (Ⅳ)

(9) CertificateVerify( 클라이언트→서버 ) 클라이언트가 CertificateVerify 메시지를 보낸다 .

(10) ChangeCipherSpec( 클라이언트→서버 ) 클라이언트가 ChangeCipherSpec 메시지를 보낸다

(11) Finished( 클라이언트→서버 ) 클라이언트가 Finished 메시지를 보낸다 .

(12) ChangeCipherSpec( 클라이언트←서버 ) 이번에는 서버가 ChangeCipherSpec 메시지를

보낸다 .

(13) Finished( 클라이언트←서버 ) 클라이언트와 마찬가지로 서버도 Finished 메시지를 보낸다 .

(14) 애플리케이션 데이터 프로토콜로 이행

핸드쉐이크 프로토콜의 목적 클라이언트는 서버의 바른 공개 키를 입수할 수 있고 , 서버를 인증할 수 있었다 . 서버는 클라이언트의 바른 공개 키를 입수할 수 있고 , 클라이언트를 인증할 수 있었다 ( 클라이언트 인증을 행하는 경우 ). 클라이언트와 서버는 암호 통신용의 공유 키를 얻을 수 있었다 . 클라이언트와 서버는 메시지 인증 코드용 공유 키를 얻을 수 있었다 .

TLS 의 핸드쉐이크 프로토콜

14.4.4 암호 사양 변경 프로토콜 TLS 핸드쉐이크 프로토콜의 일부로 암호를 변경하는 신호를 보내기 위한 것이다 .

14.4.5 경고 프로토콜 TLS 핸드쉐이크 프로토콜의 일부로 뭔가 에러가

발생했다는 것을 통신 상대에게 전하기 위한 것이다 . 핸드쉐이크 도중에 뭔가 이상이 발생했을 때 메시지 인증 코드가 잘못되어 있을 때 압축 데이터를 제대로 풀 수 없을 때

14.4.6 애플리케이션 데이터 프로토콜 TLS 핸드쉐이크 프로토콜의 일부로 애플리케이션의 데이터를 통신 상대와 주고받는 프로토콜이다 .

TLS 상에 HTTP 가 올라 있을 경우에는 , HTTP 의 요청과 응답은 TLS 의 애플리케이션 데이터 프로토콜과 TLS 레코드 프로토콜을 통해서 주고받게 된다 .

14.4.7 마스터 비밀 마스터 비밀은 TLS 의 클라이언트와 서버가 합의한 비밀 값이다 . 이 값은 매우 중요하다 .

왜냐하 면 TLS 에 의한 암호 통신의 기밀 성과 데이터 인증은 모두 이 값에 의존하고 있기 때문이다 .

마스터 비밀의 개요 마스터 비밀은 다음 정보를 기초로 해서 클라이언트와 서버가 각각 계산한다 .

사전 마스터 비밀 클라이언트 랜덤 서버 랜덤

마스터 비밀의 목적 마스터 비밀은 다음 6 개의 정보를 만들기 위한 것이다 .

대칭 암호 키 ( 클라이언트→서버 ) 대칭 암호 키 ( 클라이언트←서버 ) 메시지 인증 코드 키 ( 클라이언트→서버 ) 메시지 인증 코드 키 ( 클라이언트←서버 ) 대칭 암호 CBC 모드에서 이용하는 초기화 벡터 (클라이언트→서버 ) 대칭 암호 CBC 모드에서 이용하는 초기화 벡터 (클라이언트←서버 )

키 소재의 의존 관계

14.4.8 TLS 에서 사용되고 있는 암호 기술

TLS 레코드 프로토콜에서 사용되고 있는 암호 기술

14.5 SSL/TLS 에 대한 공격 SSL/TLS 에 대한 공격에 대해서 생각해 보자 .

14.5.1 개개의 암호 기술에 대한 공격 SSL/TLS 에서 사용되고 있는 암호 기술에 대한

공격은 , 그대로 SSL/TLS 에 대한 공격이 된다 . SSL/TLS 는 특정 암호 기술에 의존하고 있지

않다 . 어느 대칭 암호가 약하다는 것이 판명되면 , 앞으로는 그 대칭 암호를 사용하지 않는 암호 스위트를 선택하면 되는 것이다 .

14.5.2 의사난수 생성기에 대한 공격 의사난수 생성기 부분에 대한 공격이 있을 수

있다 . 1995 년 캘리포니 아 대학 버 클 리 분 교 의

대학원생 David Wagner 및 Ian Goldberg 가 Netscape Navigator 의 버그를 발견

14.5.3 인증서의 틈을 노리는 공격 SSL/TLS 에서는 클라이언트가 서버를 인증하기 위해 서버의 인증서를 사용한다 . 클라이언트가 가지고 있는 바른 인증기관의 공개 키에 의해 , 인증서에 부가되어 있는 디지털 서명을 검증하는 것이다 . 인증서를 검증하기 위해서는 최신판의 CRL( 인증서 취소 목록 ) 이 필요하다 .

14.6 SSL/TLS 의 사용자에 대한 주의 SSL/TLS 는 우리들이 빈번히 사용하는 암호 통신이지만 , SSL/TLS 를 사용하면 절대적으로 안전하다고 착각해서는 안 된다 .

14.6.1 인증서의 의미 비록 인증서가 바르더라도 , 신용카드 번호를 보낼 상대로서 반드시 신뢰할 수 있다고만은 할 수 없다는 것이다 . 상대가 카드 사기를 일삼는 회사인지 어떤지는 아무리

SSL/TLS 를 사용해도 알 수 없다 .

14.6.2 암호 통신 전의 데이터 SSL/TLS 가 지키는 것은 통신 중의 데이터이다 .

통신 전의 데이터는 지켜지고 있지 않다 . 앨리스가 브라우저에서 개인 정보를 입력하고

있는 것을 , 등 뒤에서 들여다보고 있는 사람이 있었다고 하자 .

그 사람의 눈으로부터 앨리스의 개인 정보를 지키기에는 SSL/TLS 는 아무런 도움도 되지 않는다 .

14.6.3 암호 통신 후의 데이터 SSL/TLS 는 통 신 후 의 데이터도 지 켜 주 지

않는다 . 신용카드 번호가 통신 전에 보여 지거나 , 통신

후에 도난당하거나 , 온라인 서점 자체에 의해 악용되거나 할 가능성은 남아 있다 .