사용가능한 Cipher suite 목록, Session ID, SSL Protocol Version, Random byte 등을 전달함
Cipher Suite 는 SSL Protocol version, 인증서 검증, 데이터 암호화 프로토콜, 해시 방식 등의 정보를 담고 있는 존재로 선택된 Cipher Suite 의 알고리즘에 따라 데이터를 암호화 하게 됨 https://aws-hyoh.tistory.com/39
2. Server Hello
Client 가 보내온 Client Hello Packet 을 받아서 Ciper Suite 중 하나를 선택한 다음,
Client 에게 이를 알린다.
또한, 자신의 SSL Protocol Version 도 같이 보낸다.
3. Certificate
Server 가 자신의 SSL 인증서를 Client 에게 전달함.
인증서 내부에는 Server 가 발행한 공개키 ( 개인키는 서버가 소유 ) 가 들어있음.
클라이언트는 서버가 보낸 CA 의 개인키로 암호화된 이 SSL 인증서를 이미 모두에게 공개된 CA 의 공개키를 사용하여 복호화 한다. 복호화에 성공하면, 이 인증서는 CA가 서명한 것이 맞으니 인증서를 검증할 수 있음.
잠시 인증 과정 ( 인증서 발급 과정 ) 에 대해 짚고 가겠다.
여기서 CA 란 인증 기관을 뜻한다.
인증서 발급
1. 서버는 공개키와 개인키 생성하여 자신에 대한 정보와 함께 공개키를 CA 에 전달함
2. CA 는 전달받은 정보를 바탕으로 신뢰할만한 서버인지 확인, 서버의 공개키를 담은 SSL 인증서를 생성함.
3. CA 의 개인키를 이용해서 SSL 인증서를 암호화 함. 즉, 전자 서명을 통해 해당CA 에서 발급한 인증서라는 것을 증명할 수 있게 함
4. 암호화된 SSL 인증서를 서버에 전달하고, 서버는 이를 보관함
인증서 검증
인증서는 CA 의 공개키로 복호화 할 수 있기 때문에, 브라우저가 CA 로 부터 공개키를 얻어내 인증서의 진위여부 확인 가능함
1. 브라우저가 서버와 연결을 요청하면, 서버는 자신의 SSL 인증서를 브라우저에게 전달함
-> SSL 인증서는 SSL HandShake 과정을 통해 브라우저에게 전달됨
2. 브라우저는 CA 에게 인증서 검증 요청을 함
3. CA는 자신의 공개키를 브라우저에게 전달함
4. 브라우저는 CA 공개키로 SSL 인증서를 복호화 함, 복호화 하여 서버 공개키 획득
=> 즉 이 과정은 위에 적었던 3번, Certificate 과정을 의미함
4. Server Key Exchange / Server Hello Done
Server 의 공개키가 SSL 인증서 내부에 없는 경우, 서버가 직접 전달함을 의미함
- 공개키가 있는 경우 생략되는 과정임
- DH 알고리즘이 키 교환알고리즘으로 사용되는 경우 , 공개된 특정 값을 통해 대칭키를 계산하기 때문에, 이 값을 Server Key Exchange 과정에서 전달함
5. Client Key Exchange
Client 는 Server 와 원하는 데이터를 안전하게 주고받기 위해 전달하는 데이터를 암호화 해야한다.
대칭키를 Client 가 생성하여 SSL 인증서 내부에서 추출한 Server 의 공개키를 이용해서 암호화 한 후 Server 에 전달함
사용가능한 Cipher suite 목록, Session ID, SSL Protocol Version, Random byte 등을 전달함
Cipher Suite 는 SSL Protocol version, 인증서 검증, 데이터 암호화 프로토콜, 해시 방식 등의 정보를 담고 있는 존재로 선택된 Cipher Suite 의 알고리즘에 따라 데이터를 암호화 하게 됨 https://aws-hyoh.tistory.com/39
2. Server Hello
Client 가 보내온 Client Hello Packet 을 받아서 Ciper Suite 중 하나를 선택한 다음,
Client 에게 이를 알린다.
또한, 자신의 SSL Protocol Version 도 같이 보낸다.
3. Certificate
Server 가 자신의 SSL 인증서를 Client 에게 전달함.
인증서 내부에는 Server 가 발행한 공개키 ( 개인키는 서버가 소유 ) 가 들어있음.
클라이언트는 서버가 보낸 CA 의 개인키로 암호화된 이 SSL 인증서를 이미 모두에게 공개된 CA 의 공개키를 사용하여 복호화 한다. 복호화에 성공하면, 이 인증서는 CA가 서명한 것이 맞으니 인증서를 검증할 수 있음.
잠시 인증 과정 ( 인증서 발급 과정 ) 에 대해 짚고 가겠다.
여기서 CA 란 인증 기관을 뜻한다.
인증서 발급
1. 서버는 공개키와 개인키 생성하여 자신에 대한 정보와 함께 공개키를 CA 에 전달함
2. CA 는 전달받은 정보를 바탕으로 신뢰할만한 서버인지 확인, 서버의 공개키를 담은 SSL 인증서를 생성함.
3. CA 의 개인키를 이용해서 SSL 인증서를 암호화 함. 즉, 전자 서명을 통해 해당CA 에서 발급한 인증서라는 것을 증명할 수 있게 함
4. 암호화된 SSL 인증서를 서버에 전달하고, 서버는 이를 보관함
인증서 검증
인증서는 CA 의 공개키로 복호화 할 수 있기 때문에, 브라우저가 CA 로 부터 공개키를 얻어내 인증서의 진위여부 확인 가능함
1. 브라우저가 서버와 연결을 요청하면, 서버는 자신의 SSL 인증서를 브라우저에게 전달함
-> SSL 인증서는 SSL HandShake 과정을 통해 브라우저에게 전달됨
2. 브라우저는 CA 에게 인증서 검증 요청을 함
3. CA는 자신의 공개키를 브라우저에게 전달함
4. 브라우저는 CA 공개키로 SSL 인증서를 복호화 함, 복호화 하여 서버 공개키 획득
=> 즉 이 과정은 위에 적었던 3번, Certificate 과정을 의미함
4. Server Key Exchange / Server Hello Done
Server 의 공개키가 SSL 인증서 내부에 없는 경우, 서버가 직접 전달함을 의미함
- 공개키가 있는 경우 생략되는 과정임
- DH 알고리즘이 키 교환알고리즘으로 사용되는 경우 , 공개된 특정 값을 통해 대칭키를 계산하기 때문에, 이 값을 Server Key Exchange 과정에서 전달함
5. Client Key Exchange
Client 는 Server 와 원하는 데이터를 안전하게 주고받기 위해 전달하는 데이터를 암호화 해야한다.
대칭키를 Client 가 생성하여 SSL 인증서 내부에서 추출한 Server 의 공개키를 이용해서 암호화 한 후 Server 에 전달함
