들어가며
- HTTP의 보안을 위한 레이어를 추가한 것이 HTTPS이다. 그 보안 레이어는 SSL이다. SSL의 작동원리에 대해 정리하고자 한다.
SSL의 핵심 포인트 : 대칭키와 공개키
- HTTPS를 서비스 중인 사이트에 적용 중에 있다. 이 과정에서 HTTPS 프로토콜에 대하여 다시 학습하였다. 그 과정에서 지금까지 SSL을 명확하게 이해하지 못했음을 깨달았다. 이를 이해함에 있어 가장 중요한 키포인트가 대칭키와 공개키의 차이를 아는 것임을 알게 되었다.
대칭키
- 대칭키란 동일한 키로 암호화와 복호화를 할 수 있는 방식을 의미한다.
- 웹에서 대칭키만 사용할 경우 보안 상 문제가 발생할 수 있다. 왜냐하면 대칭키의 전달 과정이 문제가 되기 때문이다. 서버가 클라이언트에게 대칭키를 전달하는 과정에서, 해당 대칭키는 암호화 될 수 없기 때문이다.
공개키
- 공개키를 우리는 공개키라 명명하지만, 사실 공개키 방식에는 키가 두 개가 있다. 공개키와 비밀키이다. 비밀키로 작성한 값은 공개키로만 열 수 있고, 공개키로 작성한 값은 비밀키로만 열 수 있다.
- 이 방식의 강점은 대칭키와 달리 공개된 공간에서 보안을 확보할 수 있다. 왜냐하면 클라이언트가 서버에 전달하는 데이타는 비밀키를 가진 서버만 복호화 할 수 있기 때문이다.
- 부수적으로 이 과정에서 클라이언트는 서버가 자신이 가진 공개키에 대응하는 비밀키를 가지고 있는지 확인할 수 있다. 서버가 비밀키로 어떤 값을 암호화를 하여 클라이언트에 전달하면, 클라이언트는 공개키를 가지고 해당 값을 복호화 할 수 있다. 만약 비밀키가 다르면, 클라이언트는 그 값을 복호화 할 수 없다.
- (이후 논의) 하지만 문제는 공개키는 대칭키에 대비하여 느리다고 한다. 이에 대한 보안책으로 서버와 클라이언트 간 악수(HandShake) 과정을 거치며 이 때 대칭키를 교환한다. 악수 때는 공개키로 통신하고, 악수 이후 세션 과정에서는 대칭키로 통신한다.
- (이후 논의) 공개키는 CA와 연계하여 클라이언트 입장에서 서버가 안전한지를 확인할 수 있다.
브라우저와 SSL
- 서버는 자체적인 공개키를 생성하여 클라이언트에게 제공한다면, 이미 클라이언트와 서버 간 보안을 확보할 수 있다.
- 하지만 클라이언트 입장에서 서버의 보안 방식이 정말로 안전한지 확인할 방법이 없다. 보안 과정이 공인된 제 3자에게 보장 받을 수 없을까? 이를 CA라 한다.
- 브라우저는 종류와 버전과 사용 가능한 CA와 공개키가 다르다. 그러므로 CA 선정을 잘 해야 한다.
CA
- CA는 SSL 인증 기관이다.
- 서버는 CA로부터 SSL 인증서를 발급받는다. 서버는 인증서 발급 과정에서 자신의 비밀키를 입력한다.
- 클라이언트가 서버에 접속한다. 서버는 클라이언트에게 SSL 인증서를 제공한다. 클라이언트는 인증서를 가지고 1) 해당 CA에 접속하여 서버가 등록되어 있는 곳인지를 확인하며 2) 해당 CA로부터 받은 공개키로 서버에서 암호화 한 값을 복호화 한다. 1)과 2) 를 통과하면 클라이언트는 해당 서버가 안전함을 확인할 수 있다.
- 그러므로 HTTPS의 공개키는 정확하게 CA의 공개키를 의미하며, 비밀키는 서버가 임의로 설정한 값을 의미한다.
SSL의 동작방법
- 서버와 클라이언트는 악수를 통해 대칭키를 교환한다.
악수(handshake)
- 클라이언트가 서버에 접속한다.
- 서버는 클라이언트에게 SSL 인증서를 제공한다.
- 클라이언트는 인증서와 CA, 복호화를 통해 서버가 안전한지를 확인한다.
- 악수의 과정에서 서버와 클라이언트는 서로 랜덤 데이터를 전달한다.
- 클라이언트는 서버와 클라이언트가 생성한 랜덤 데이터를 통해 대칭키를 생성한다.
세션
- 대칭키를 통해 서버와 클라이언트가 데이터를 주고 받는 단계
세션 종료
- 통신이 종료된 대칭키 폐기한다.
JAVA web developer