1 / 61

제 14 장 SSL/TLS

제 14 장 SSL/TLS. 안전한 통신을 위해. 14.1 주요 내용. SSL(Secure Socket Layer ) TLS(Transport Layer Security) 전자 상거래가 활발해지면서 웹 보안이 매우 중요한 주제가 되고 있다 . 웹 서버 상의 자료를 보호하고 웹 서버에 접속하는 사용자의 안전한 상거래를 위해서 필요한 여러 보안 조치들이 개발되었다 . 그 중의 한 가지가 SSL/TLS 이다. 14.2 웹 보안. 암호 알고리즘을 조정하는 정보 조각 평문을 암호문으로 전환

fay
Download Presentation

제 14 장 SSL/TLS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

  8. 웹에 대한 위협

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

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

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

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

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

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

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

  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. 14.3.6 암호 스위트 • 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. 14.4.2 TLS 레코드 프로토콜 • TLS 레코드 프로토콜로 수행하는 것은 메시지의 압축, 암호화, 그리고 데이터의 인증이다.

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

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

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

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

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

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

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

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

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

  42. (13) Finished(클라이언트←서버) • 클라이언트와 마찬가지로 서버도 Finished 메시지를 보낸다. • (14) 애플리케이션 데이터 프로토콜로 이행

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

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

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

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

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

  48. 14.4.7 마스터 비밀 • 마스터 비밀은 TLS의 클라이언트와 서버가 합의한 비밀 값이다. • 이 값은 매우 중요하다. • 왜냐하면 TLS에 의한 암호 통신의 기밀성과 데이터 인증은 모두 이 값에 의존하고 있기 때문이다.

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

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

More Related