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

Presentation on theme: "제 14장 SSL/TLS 안전한 통신을 위해."— Presentation transcript:

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

2 14.1 주요 내용 SSL(Secure Socket Layer ) TLS(Transport Layer Security)
전자 상거래가 활발해지면서 웹 보안이 매우 중요한 주제가 되고 있다. 웹 서버 상의 자료를 보호하고 웹 서버에 접속하는 사용자의 안전한 상거래를 위해서 필요한 여러 보안 조치들이 개발되었다. 그 중의 한 가지가 SSL/TLS이다.

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

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

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

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

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

8 웹에 대한 위협

9 14.2.3 웹 트래픽 보안 방법 웹의 응용 범위나 TCP/IP 프로토콜 계층에서 웹의 상대적 위치에 따른 웹 보안 방법
IPSec 응용프로그램별로 보안을 제공하는 방법 응용계층과 전송계층 사이에서 보안조치를 취하는 웹 보안 방법 전송계층의 프로토콜인 TCP 바로 위에서 보안을 구현하는 것. 이 방법의 가장 좋은 예는 SSL/TLS이다

10 14.3 SSL/TLS란 언제나처럼 앨리스와 밥을 등장시켜 SSL/TLS가 사용되는 시나리오를 생각해보자.

11 온라인 상거래 신용카드 번호를 입력하는 페이지의 URL은 아니고 문자열로 시작되고 있다 웹 브라우저 하단에 자물쇠 마크가 작게 표시되어 정말로 안전하게 보인다 웹 브라우저의 자물쇠 마크는 SSL/TLS에 의해 통신이 지켜지고 있다는 증거로서 표시되고 있는 것이다

12 클라이언트와 서버 우선 앨리스와 밥 서점 사이의 통신을 이용해서 설명해보자

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

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

15 SSL/TLS 상의 HTTP 통신 내용을 암호화해 주는 프로토콜로서 SSL(Secure Socket Layer) 혹은 TLS(Transport Layer Security)를 이용한다. 그리고 SSL/TLS 상에 HTTP를 올리는 것이다 이것은 프로토콜의 이중 구조이다. 이것에 의해 HTTP의 통신(요청과 응답)은 암호화되어 도청을 방지할 수 있다. SSL/TLS로 통신을 수행할 때의 URL은 아니고 시작된다.

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

17 14.3.4 SSL/TLS의 역할 앨리스는 웹 브라우저를 사용해서 밥 서점에 신용카드 번호를 보내고 싶은 것이다.
여기에는 풀지 않으면 안 되는 문제가 몇 개 있다. (1) 앨리스가 송신하는 신용카드 번호와 주소를 「도청」당하는 일 없이 밥 서점에 보내고 싶다. (2) 앨리스가 송신하는 신용카드 번호와 주소를 「수정」당하는 일 없이 밥 서점에 보내고 싶다. (3) 통신 상대의 웹 서버가 「진짜 밥 서점」이라는 것을 확인하고 싶다.

18 14.3.5 SSL/TLS와 다른 프로토콜 SSL/TLS 상에는 HTTP뿐만 아니라, 다른 프로토콜도 올릴 수 있다.
예를 들면 메일을 전송하기 위한 SMTP(Simple Mail Transfer Protocol)나, 메일을 수신하기 위한 POP3(Post Office Protocol)와 같은 프로토콜을 SSL/TLS 상에 올릴 수도 있다. 이 경우에 SSL/TLS는 송수신하는 메일을 지키고 있는 셈이다.

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

20 암호 스위트 SSL/TLS에서 사용하는 대칭 암호, 공개 키 암호, 디지털 서명, 일방향 해시 함수 등은 부품과 같이 교환할 수 있다 사용하고 있던 암호 기술에 결함이 발견되었을 때는 그 부분을 교체할 수 있는 모듈화된 프레임워크이다 암호 기술의 「추천 세트」가 SSL/TLS로 규정되어 있다. 이 추천 세트를 암호 스위트(cipher suite)라고 한다.

21 14.3.7 SSL과 TLS의 차이 SSL과 TLS는 골자는 같지만 미묘한 차이가 있다
SSL(Secure Socket Layer) 1994년 Netscape사에 의해 만들어졌고 웹 브라우저인 Netscape Navigator에 내장되었다. 그 후 많은 웹 브라우저에서 사용되어 사실상의 업계의 표준이 되었다. SSL은 1995년에 Version 3.0이 되었다.

22 TLS(Transport Layer Security)
SSL 3.0을 기초로 해서 IETF가 만든 프로토콜이다. 1999년에 RFC2246으로서 발표된 TLS 1.0은 SSL 3.1에 해당되는 것이다.

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

24 14.4.1 계층화된 프로토콜 구성 TLS 레코드 프로토콜 TLS 핸드쉐이크 프로토콜 암호화 처리
암호화 이외의 다양한 처리를 수행 4개의 서브 프로토콜로 나누어진다

25 TLS 프로토콜 계층

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

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

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

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

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

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

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

33 TLS 레코트 프로토콜의 처리

34 핸드쉐이크 프로토콜 핸드쉐이크 프로토콜은 TLS 핸드쉐이크 프로토콜의 일부로 공유 키를 생성하고 인증서를 교환하기 위한 것이다. 공유 키를 생성하는 것은 암호 통신을 행하기 위한 것이고, 인증서를 교환하는 것은 서로 상대를 인증하기 위한 것이다.

35 절차 (1) ClientHello(클라이언트→서버) 클라이언트가 서버에게 ClientHello라는 메시지를 보낸다.
보내지는 정보 사용할 수 있는 버전 번호 현재 시각 클라이언트 랜덤 세션 ID 사용할 수 있는 암호 스위트 목록 사용할 수 있는 압축 방법 목록

36 (2) ServerHello(클라이언트←서버)
클라이언트로부터 받은 ClientHello에 대해, 서버는 ServerHello라고 하는 메시지를 보낸다. 추가되는 정보 사용하는 버전 번호 현재 시각 서버 랜덤 세션 ID 사용하는 암호 스위트 사용하는 압축 방법

37 (3) Certificate(클라이언트←서버)
추가되는 메시지 인증서 목록 (4) ServerKeyExchange(클라이언트←서버) 서버가 ServerKeyExchange 메시지를 보낸다.

38 (5) CertificateRequest(클라이언트←서버)
보내지는 정보 서버가 이해할 수 있는 인증서 타입 목록 서버가 이해할 수 있는 인증기관 이름 목록 (6) ServerHelloDone(클라이언트←서버)   서버가 ServerHelloDone 메시지를 보낸다. (7) Certificate(클라이언트→서버)   클라이언트가 Certificate 메시지를 보낸다.

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

40 사전 마스터 비밀이란 클라이언트가 만든 난수 후에 마스터 비밀(Master Secret)을 만들기 위한 종자
이 값은 서버의 공개 키로 암호화해서 서버에게 보낸다 사전 마스터 비밀을 사용해서 서버와 클라이언트는 공통의 마스터 비밀을 계산한다. 그리고 마스터 비밀을 기초로 해서 다음과 같은 비트 열(키 소재)을 만든다 대칭 암호 키 메시지 인증 코드 키 대칭 암호의 CBC 모드에서 이용하는 초기화 벡터(Ⅳ)

41 (9) CertificateVerify(클라이언트→서버) (10) ChangeCipherSpec(클라이언트→서버)
(11) Finished(클라이언트→서버)   클라이언트가 Finished 메시지를 보낸다. (12) ChangeCipherSpec(클라이언트←서버)   이번에는 서버가 ChangeCipherSpec 메시지를 보낸다.

42 (13) Finished(클라이언트←서버)
(14) 애플리케이션 데이터 프로토콜로 이행

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

44 TLS의 핸드쉐이크 프로토콜

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

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

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

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

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

50 마스터 비밀의 목적 마스터 비밀은 다음 6개의 정보를 만들기 위한 것이다. 대칭 암호 키(클라이언트→서버)
대칭 암호 키(클라이언트←서버) 메시지 인증 코드 키(클라이언트→서버) 메시지 인증 코드 키(클라이언트←서버) 대칭 암호 CBC 모드에서 이용하는 초기화 벡터(클라이언트→서버) 대칭 암호 CBC 모드에서 이용하는 초기화 벡터(클라이언트←서버)

51 키 소재의 의존 관계

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

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

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

55 개개의 암호 기술에 대한 공격 SSL/TLS에서 사용되고 있는 암호 기술에 대한 공격은, 그대로 SSL/TLS에 대한 공격이 된다. SSL/TLS는 특정 암호 기술에 의존하고 있지 않다. 어느 대칭 암호가 약하다는 것이 판명되면, 앞으로는 그 대칭 암호를 사용하지 않는 암호 스위트를 선택하면 되는 것이다.

56 14.5.2 의사난수 생성기에 대한 공격 의사난수 생성기 부분에 대한 공격이 있을 수 있다.
1995년 캘리포니아대학 버클리 분교의 대학원생 David Wagner 및 Ian Goldberg가 Netscape Navigator의 버그를 발견

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

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

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

60 암호 통신 전의 데이터 SSL/TLS가 지키는 것은 통신 중의 데이터이다. 통신 전의 데이터는 지켜지고 있지 않다. 앨리스가 브라우저에서 개인 정보를 입력하고 있는 것을, 등 뒤에서 들여다보고 있는 사람이 있었다고 하자. 그 사람의 눈으로부터 앨리스의 개인 정보를 지키기에는 SSL/TLS는 아무런 도움도 되지 않는다.

61 14.6.3 암호 통신 후의 데이터 SSL/TLS는 통신 후의 데이터도 지켜 주지 않는다.
신용카드 번호가 통신 전에 보여 지거나, 통신 후에 도난당하거나, 온라인 서점 자체에 의해 악용되거나 할 가능성은 남아 있다.