SSL의 통신과정
SSL 인증서의 역할
1. 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.
2. SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.
CA : 인증서 발급 기관
SSL 인증서를 발급해주는 민간기업들을 CA(Certificate Authority) 라고 부른다. 인증서는 개인키 소유자의 공개키에 인증기관의 개인키로 전자서명한 데이터다. 모든 인증서는 발급 기관(CA)이 있어야 하나 최상위 인증기관(Root CA)은 서명해줄 상위 인증기관이 없으므로 Root CA의 개인키로 스스로의 인증서에 서명하여 최상위 인증기관 인증서를 만든다. 이렇게 스스로 서명한 Root CA 인증서를 Self Signed Certificate 라고 부른다. CA는 신뢰성이 엄격하게 공인된 기업들만이 참여할 수 있다.
공인CA와 사설CA
만약, 네이버나 다음과 같이 공개된 사이트에 접속한 클라이언트에게는 1, 2번을 모두 충족시킬 필요가 있다. 하지만 개인적인 개발이 목적이라면 사이트에 접속하는 클라이언트가 나 자신 또는 팀원 밖에 없고, 그 도메인이 그 사이트라는 것을 인지하고 있기 때문에(=SSL 인증서의 역할 1번을 이미 충족함.) SSL 인증서의 2번 역할인 암호화 기능만을 사용하려면 사설 CA를 이용하면 된다. (2번 역할인 공개키를 클라이언트에게 제공하는 것이 어떻게 암호화 기능을 하는 지는 아래의 핸드쉐이크 단계 3-3 ~ 에서 알 수 있다.)
SSL 인증서의 내용
1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등)
2. 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)
SSL 인증서 전달의 개요
서버는 자기가 생성한 공개키와 함께 서비스에 대한정보를 묶어서 인증기관에 전송하면 인증기관에서 심의한 후 문제가 없으면 인증서를 서비스에 다시 제공, 그 서비스는 그 인증서를 자신의 서비스에 접속하는 사용자에게 제공
필수 기본 개념
브라우저에는 CA의 리스트(CA의 공개키 포함)가 저장되어있다. CA 리스트에 포함된 CA만 공인된 CA인 것이다.
SSL 인증서의 역할 두가지를 알아봤었다.
이제 그 첫번째 역할 '클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장'하는 과정을 알아보자. 먼저 웹 브라우저가 서버에 접속할 때 서버는 웹 브라우저에 인증서를 제공한다. 브라우저는 이 인증서를 발급한 CA가 리스트에 있는지 확인한다. 만약 리스트에 있다면 해당 CA의 공개키를 이용해서 복호화한다. 복호화에 성공하면 '클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장'한 것이다. 왜냐하면 '공개키 방식에서 공개키로 복호화가능하다면 그 데이터는 해당 비밀키로 암호화한 것이다'는 것을 역설적으로 인증하게 된다.
SSL의 통신 방법 : 대칭키 방식 + 공유키 방식
클라이언트와 서버가 통신한때 이상적인 통신은 공개키방식이다. C/S 둘다 비밀키를 가지고 서로에게 공개키를 전송하여 간단하게 암호화 통신을 할수있다.(전송하는 쪽: 공개키로 암호화 -> 받는 쪽: 비밀키로 복호화) 하지만 이 방식은 암,복호화하는데 컴퓨팅 파워가 너무 크다는 문제점이 있다. 반면 대칭키 방식은 보안상 문제가 있다. 그래서 SSL은 두가지 방식을 함께 사용하여 성능상의 이점을 살리면서 암호화를 구현한다.
대칭키 방식은 세션단계에서 데이터를 암호화하는데 사용 - 컴퓨팅 파워 낮음(알고리즘 덜복잡, 빠른 속도)
공개키 방식은 대칭키 방식의 대칭키를 공유할 때 공개키 방식을 사용함(정확히는 대칭키가 아니라 대칭키를 생성하는 Master Secret 키 - 더 정확히는 Master Secret 키를 생성한 Pre-Master Secret 키이다. // 3-3.참고)
아래의 그림을 참고하면서 이해해보자.
(출처 : IBM-Overview of the SSL or TLS handshake)
컴퓨터-컴퓨터 네트워크 통신의 3단계는 아래와 같다.
'악수 -> 전송 -> 세션종료'
핸드쉐이크 단계
1. 클라이언트가 서버에 접속한다.(Client Hello)
서버에 전송되는 데이터
- 클라이언트에서 생성한 랜덤 데이터
- 클라이언트가 지원하는 암호화 방식들
- 세션 아이디
2. 서버가 클라이언트에 응답(전송)한다.(Server Hello)
클라이언트에 전송되는 데이터
- 서버에서 생성한 랜덤 데이터
- 서버가 선택한 클라이언트의 암호화 방식
- 인증서(서버의 공개키가 포함됨)
3-1. 클라이언트는 클라이언트(웹브라우저)의 CA리스트를 확인하여 인증서가 CA에 의해서 발급된 것인지 확인한다. 웹브라우저에 내장된 CA의 공개키를 이용해서 인증서를 복호화하는 데 성공하면 이 인증서를 전송한 서버가 신뢰가능한 서버라는 것이 보증된다. 반면, 리스트에 없거나 복호화에 실패하면 사용자에게 경고 메시지를 출력한다.
3-2. 클라이언트는 서버와 클라이언트에서 생성된 랜덤 데이터를 조합해서 Pre-Master Secret 키를 생성한다. (이 키는 뒤에서 살펴볼 '세션 단계'에서 데이터를 주고 받을 때 암호화하기 위해서 사용된다. 이 때 사용할 암호화 기법은 대칭키 방식이기 때문에 pre master secret 값은 제 3자에게 절대로 노출되어서는 안된다)
3-3. 인증서에 포함된 공개키로 pre master secret 값을 암호화해서 서버로 전송한다.
4-1. 서버는 자신의 비공개키로 안전하게 복호화한다. (이 시점에 C/S가 모두 Pre-Master Secret 값을 가지게 되었다.)
4-2. C/S 모두 일련의 과정을 거쳐서 Pre-Master Secret 값을 Master Secret 값으로 만든다.
4-3. master secret은 session key를 생성한다.
5. C/S는 서로에게 핸드쉐이크 단계의 종료를 알린다.
세션(전송) 단계
session key 값을 이용해서 서버와 클라이언트는 대칭키 방식으로 데이터를 암호화한 후에 주고 받는다. (session key값이 대칭키 방식의 대칭키이다, pre master secret 값은 외부에 노출되지 않았다 -> master secret 값도 마찬가지 -> session key도 마찬가지라서 대칭키의 역할이 가능하다)
세션 종료
데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 그리고 통신에서 사용한 대칭키인 세션키를 폐기한다.
참고하면 좋은 사이트
암호화 보안 프로토콜: SSL 및 TLS
웹사이트는 어떻게 보여지게 되는 걸까?
OpenSSL로 ROOT CA 생성 및 SSL 인증서 발급
1. 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.
2. SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.
CA : 인증서 발급 기관
SSL 인증서를 발급해주는 민간기업들을 CA(Certificate Authority) 라고 부른다. 인증서는 개인키 소유자의 공개키에 인증기관의 개인키로 전자서명한 데이터다. 모든 인증서는 발급 기관(CA)이 있어야 하나 최상위 인증기관(Root CA)은 서명해줄 상위 인증기관이 없으므로 Root CA의 개인키로 스스로의 인증서에 서명하여 최상위 인증기관 인증서를 만든다. 이렇게 스스로 서명한 Root CA 인증서를 Self Signed Certificate 라고 부른다. CA는 신뢰성이 엄격하게 공인된 기업들만이 참여할 수 있다.
공인CA와 사설CA
만약, 네이버나 다음과 같이 공개된 사이트에 접속한 클라이언트에게는 1, 2번을 모두 충족시킬 필요가 있다. 하지만 개인적인 개발이 목적이라면 사이트에 접속하는 클라이언트가 나 자신 또는 팀원 밖에 없고, 그 도메인이 그 사이트라는 것을 인지하고 있기 때문에(=SSL 인증서의 역할 1번을 이미 충족함.) SSL 인증서의 2번 역할인 암호화 기능만을 사용하려면 사설 CA를 이용하면 된다. (2번 역할인 공개키를 클라이언트에게 제공하는 것이 어떻게 암호화 기능을 하는 지는 아래의 핸드쉐이크 단계 3-3 ~ 에서 알 수 있다.)
SSL 인증서의 내용
1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등)
2. 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)
SSL 인증서 전달의 개요
서버는 자기가 생성한 공개키와 함께 서비스에 대한정보를 묶어서 인증기관에 전송하면 인증기관에서 심의한 후 문제가 없으면 인증서를 서비스에 다시 제공, 그 서비스는 그 인증서를 자신의 서비스에 접속하는 사용자에게 제공
필수 기본 개념
브라우저에는 CA의 리스트(CA의 공개키 포함)가 저장되어있다. CA 리스트에 포함된 CA만 공인된 CA인 것이다.
SSL 인증서의 역할 두가지를 알아봤었다.
이제 그 첫번째 역할 '클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장'하는 과정을 알아보자. 먼저 웹 브라우저가 서버에 접속할 때 서버는 웹 브라우저에 인증서를 제공한다. 브라우저는 이 인증서를 발급한 CA가 리스트에 있는지 확인한다. 만약 리스트에 있다면 해당 CA의 공개키를 이용해서 복호화한다. 복호화에 성공하면 '클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장'한 것이다. 왜냐하면 '공개키 방식에서 공개키로 복호화가능하다면 그 데이터는 해당 비밀키로 암호화한 것이다'는 것을 역설적으로 인증하게 된다.
SSL의 통신 방법 : 대칭키 방식 + 공유키 방식
클라이언트와 서버가 통신한때 이상적인 통신은 공개키방식이다. C/S 둘다 비밀키를 가지고 서로에게 공개키를 전송하여 간단하게 암호화 통신을 할수있다.(전송하는 쪽: 공개키로 암호화 -> 받는 쪽: 비밀키로 복호화) 하지만 이 방식은 암,복호화하는데 컴퓨팅 파워가 너무 크다는 문제점이 있다. 반면 대칭키 방식은 보안상 문제가 있다. 그래서 SSL은 두가지 방식을 함께 사용하여 성능상의 이점을 살리면서 암호화를 구현한다.
대칭키 방식은 세션단계에서 데이터를 암호화하는데 사용 - 컴퓨팅 파워 낮음(알고리즘 덜복잡, 빠른 속도)
공개키 방식은 대칭키 방식의 대칭키를 공유할 때 공개키 방식을 사용함(정확히는 대칭키가 아니라 대칭키를 생성하는 Master Secret 키 - 더 정확히는 Master Secret 키를 생성한 Pre-Master Secret 키이다. // 3-3.참고)
아래의 그림을 참고하면서 이해해보자.
(출처 : IBM-Overview of the SSL or TLS handshake)
컴퓨터-컴퓨터 네트워크 통신의 3단계는 아래와 같다.
'악수 -> 전송 -> 세션종료'
핸드쉐이크 단계
1. 클라이언트가 서버에 접속한다.(Client Hello)
서버에 전송되는 데이터
- 클라이언트에서 생성한 랜덤 데이터
- 클라이언트가 지원하는 암호화 방식들
- 세션 아이디
2. 서버가 클라이언트에 응답(전송)한다.(Server Hello)
클라이언트에 전송되는 데이터
- 서버에서 생성한 랜덤 데이터
- 서버가 선택한 클라이언트의 암호화 방식
- 인증서(서버의 공개키가 포함됨)
3-1. 클라이언트는 클라이언트(웹브라우저)의 CA리스트를 확인하여 인증서가 CA에 의해서 발급된 것인지 확인한다. 웹브라우저에 내장된 CA의 공개키를 이용해서 인증서를 복호화하는 데 성공하면 이 인증서를 전송한 서버가 신뢰가능한 서버라는 것이 보증된다. 반면, 리스트에 없거나 복호화에 실패하면 사용자에게 경고 메시지를 출력한다.
3-2. 클라이언트는 서버와 클라이언트에서 생성된 랜덤 데이터를 조합해서 Pre-Master Secret 키를 생성한다. (이 키는 뒤에서 살펴볼 '세션 단계'에서 데이터를 주고 받을 때 암호화하기 위해서 사용된다. 이 때 사용할 암호화 기법은 대칭키 방식이기 때문에 pre master secret 값은 제 3자에게 절대로 노출되어서는 안된다)
3-3. 인증서에 포함된 공개키로 pre master secret 값을 암호화해서 서버로 전송한다.
4-1. 서버는 자신의 비공개키로 안전하게 복호화한다. (이 시점에 C/S가 모두 Pre-Master Secret 값을 가지게 되었다.)
4-2. C/S 모두 일련의 과정을 거쳐서 Pre-Master Secret 값을 Master Secret 값으로 만든다.
4-3. master secret은 session key를 생성한다.
5. C/S는 서로에게 핸드쉐이크 단계의 종료를 알린다.
세션(전송) 단계
session key 값을 이용해서 서버와 클라이언트는 대칭키 방식으로 데이터를 암호화한 후에 주고 받는다. (session key값이 대칭키 방식의 대칭키이다, pre master secret 값은 외부에 노출되지 않았다 -> master secret 값도 마찬가지 -> session key도 마찬가지라서 대칭키의 역할이 가능하다)
세션 종료
데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 그리고 통신에서 사용한 대칭키인 세션키를 폐기한다.
참고하면 좋은 사이트
암호화 보안 프로토콜: SSL 및 TLS
웹사이트는 어떻게 보여지게 되는 걸까?
OpenSSL로 ROOT CA 생성 및 SSL 인증서 발급
댓글
댓글 쓰기