SSL(Secure Sockets Layer)
클라이언트와 서버간의 통신을 제 3자가 보증화 해주는 전자화된 문서- 통신내용이 공격자에게 노출되고 악의적으로 변경되는 것을 막고 서버의 신뢰성을 올릴 수 있다.
- 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버인지를 판단하고 SSL 통신에 사용될 공개키를 클라이언트에게 전달하는 것이다.
SSL인증서에는 두가지 내용이 들어간다.
1. 서비스의 정보(CA, 도메인)
2. 서버측 공개키CA란? SSL 인증서를 기준으로 클라이언트가 접속한 서버가 의도한 서버인지 확인을 하게 된다. 이러한 일들을 해주는 공인된 회사들을 CA라고 한다. 이러한 CA는 브라우저가 리스트를 가지고 있고 이 CA들의 공개키들을 가지고 있다.
인증서로 서버가 신뢰할 수 있는지 판단하는 법
- 공개키 서명 방식을 사용한다.
- 서버는 SSL 인증서를 제공(인증서에는 서버측의 공개키, 서비스의 정보를 포함)
- 브라우저는 인증서를 발급한 CA가 자신의 CA리스트에 있는지 확인
- 리스트에 있다면 CA의 해당 공개키를 이용해서 인증서를 복호화
(복호화가 된다면 이 인증서는 CA의 비공개키에 의해 암호화 되었다는 것을 알 수 있다.)
SSL Handshake
1. client Hello: client에서 SSL버전 정보와 지원하는 암호화 방식, 무작위 바이트 문자열(이후 중요하게 사용되는 데이터)이 포함되어 전달(전에 사용했다면 세션을 재사용 가능)
2. sever hello: 지원하는 암호화 방식 중 서버에서 어떤것을 사용할 지, 세션 ID, 서버측에서 생성한 무작위 바이트 문자열을 전송(클라이언트에서 인증서를 요구하면 SSL 인증서를 전송)
3. 인증서를 받게 되면 공개키 방식으로 신뢰할 수 있는 사이트인지를 판단(클라이언트는 공개키를 얻게됨)
4. 이후 클라이언트는 자신이 만든 무작위 바이트 문자열과 서버쪽에서 전송된 무작위 바이트 문자열을 조합하여 pre master secret키를 생성(이 키는 데이터를 주고 받는 과정에서 대칭키 방식을 사용할 때 사용)
이 pre master secret키를 서버로 전송할 때 인증서에서 받았던 키를 이용하여 공개키 방식으로 암호화 후 서버쪽으로 전송
5. 서버쪽에서는 수신한 pre master secret키를 복호화(비밀키를 이용)
6, sever client 둘 다 일련의 과정을 거쳐 pre master secret키를 master key로 만들게 되고 이 master key를 이용하여 session key를 만듦(이후 데이터를 주고 받을 때 session key를 대칭키 방식을 이용해 통신)
7. 통신이 끝나면 세션키를 폐기
TLS(Transport Layer Security)
인터넷 상의 커뮤니케이션에서 개인 정보와 데이터 보안을 위해 설계되어 널리 채택된 보안 프로토콜사용 사례
- 웹 브라우저와 서버간의 통신 데이터를 암호화
TLS가 하는 것
- 암호화: 제 3자로부터 전송되는 데이터를 숨김
- 인증: 정보를 교환하는 당사자가 요청된 당사자임을 보장
- 무결성: 데이터가 위조되거나 변조되지 않았는지 확인
TLS Handshake
클라이언트는 서버의 인증서를 받아 서버의 무결성을 확인하고 신뢰할 수 있는 서버라면, 암호화 통신에 사용할 대칭키를 서버의 공개키로 암호화 하여 전달
여기서 데이터를 주고 받기 전, 서버의 무결성을 확인하고 대칭키를 전달하는 과정 -> TLS HandShake
TLS HandShake를 하는 동안 클라이언트와 웹 서버는 아래일을 수행
- 사용할 TLS 버전 지정
- 사용할 암호 제품군 결정(공유된 암호화 키 또는 세션 키와 같은 세부 정보를 명시하는 알고리즘 집합
- 서버의 TLS 인증서를 사용하여 서버의 신원을 인증
- Handshake가 완료된 후 메시지를 암호화하기 위한 세션 키 생성
진행과정
1. Client: Client Hello
클라이언트가 서버에서 Client Hello 메시지 전송
패킷 내에는 TLS Version, Client가 지원하는 암호화 방식, Client Random Data(클라이언트에서 생성한 난수로 대칭키를 만들 때 사용), Session ID, SNI(서버명)이 포함
2. Sever: Server Hello
클라이언트가 보낸 Client Hello에 대한 서버의 응답
TLS Version, 암호화 방식(클라이언트가 보낸 암호화 방식 중 서버가 사용 가능한 암호화 방식을 선택), Server Random Data(서버에서 생성한 난수, 대칭키를 만들 때 사용), Session ID
3. Server : Server Certificate
서버의 인증서를 클라이언트에게 보내는 단계로 필요에 따라 CA의 Certificate도 함께 전송
클라이언트는 이 패킷을 통해 서버의 인증서가 무결한지 검증한다.
4. Server : Server Hello Done
서버가 클라이언트에게 보낼 메시지를 모두 보냈다는 뜻
5. Client : Client Key Exchange
- 인증서가 무결한 지 검증되었으면 클라이언트의 난수와 서버의 난수를 조합하여 대칭키를 생성(대칭키를 서버의 공개키로 암호화)
- 암호화한 정보를 서버에게 전송
6. Server & Client : Change Cipher Spec
이제부터 전송되는 모든 패킷은 협상된 알고리즘과 키를 이용하여 암호화 하겠다고 알리는 메시지
7. Server & Client : Finished
TLS Handshake를 성공적으로 마치고 종료
TLS와 SSL의 차이점
위의 내용을 읽다보면 둘의 큰 차이점이 명확하게 다가오지 않는다
우선 차이점을 알려면 TLS는 SSL 3.0 버전을 기반으로 개발된 프로토콜이다.
- 서로 다른 암호를 사용하는 프로토콜이다.
(SSL2와 SSL3은 상호 운영되지 않고, SSL3와 TLS1도 서로 호환되지 않는다.) - 서버 수성 측면에서 볼 때, 취약점, 구식 암호 제품군 및 브라우저 보안 경고의 차이가 있는 프로토콜이라고 할 수 있다.
SSL과 TLS를 구분하여 보기도 하지만, SSL을 참고하여 표준화된 것이 TLS이기 때문에 둘은 본질적으로 기능과 용도가 같아 붙여서 사용하곤 한다.추가로,
HTTPS는 HTTP에 보안용 프로토콜인 SSL/TLS가 조합된 프로토콜이다.
참고한 블로그 링크
