👉 SSL
클라이언트와 서버간의 데이터가 암호화 되지 않는다면
비밀번호와 같은 민감 정보를 통신 중간에 해킹당하기 쉬울 수 밖에 없습니다.
브라우저 사용자는 서비스 제공자가 위와 같은 해킹에 취약한지 주소창에 있는
자물쇠 모양으로 쉽게 파악할 수 있습니다.
html과 같은 hyper text 를 통신하는 http에 보안 요소를 추가한 것이
Hyper Text Markup Language over Secure Sock Layer (이하: HTTPS)입니다.
본 포스트는 SSL이 클라이언트와 서버 통신 콘텐츠를 암호화 하는데 어떻게 도움을 주는지 이야기 해보려고 합니다.
👉 대칭키와 공개키
우리 집 현관문 도어락 비밀번호는 여러개가 아닙니다. 한 가지로 설정해 놓고 온 가족이 다 공유해 사용하죠. 친구와 비밀일기를 교환할때 자물쇠를 잠글 때 사용하는 비밀번호는 다시 자물쇠를 풀 때 동일하게 사용됩니다.
대칭키
암호화와 복호화에 동일한 비밀번호(키)를 사용하는 방식을 대칭키 방식을 사용한다. 라고 합니다. 문제는 이 키를 제 3자가 알아버린다면 의도치 않는 정보 유출이 일어날 수 있어 공개키보다 상대적으로 취약하다고 할 수 있습니다.
공개키 ( 비대칭 )
{ 공개 키 : 비공개 키} 의 한 pair 쌍으로 이뤄져 있는 이 암호화 방식은 비공개 키(private key)는 아무에게도 보여주지 않고 꽁꽁 감춰두고 공개키만 공유합니다.
누군가 공개키로 암호화한 정보를 나에게 전달해주면 품 안에 고이 숨겨둔 private key를 이용해 해당 정보를 복호화하면 되죠.
서버에서 비공개 키를 사용해서 암호화한 내용이 클라이언트에게 전달이 되었습니다. 공개키가 유출되어서 서버쪽 내용을 아무나 열어볼 수 있으면 안좋은 게 아닐까요?
그런데 이렇게 생각해 볼 수도 있을 것 같은데요, 서버가 발급한 공개키를 통해 내가 해당 정보를 열어볼 수 있기만한다면 해당 서버는 신뢰할 수 있는 서비스 제공자라는 것을요. 신원 확인을 할 수 있다는 것에 의미를 둔다면 이용할 가치가 있을 것 같습니다.
👉 SSL 인증서 - 신뢰도 유무 판단
공개키 제공은 개인용 PC 서버에서도 제공할 수 있습니다. 그런데 실제 서비스에는 더욱 확실한 보안이 요구됩니다.
클라이언트와 서버가 키를 주고 받기 이전에 서비스를 제공하는 회사가 확실한 보안을 제공하는지, 신뢰할 수 있는지 확인해주는 기업이 있는데요, CA(certificate authority)는 엄격한 기준에 통과된 기업들로만 선정됩니다.
대표적인 기업으로는 Symantec, Comodo등이 있습니다.
서비스 제공자는 CA에게 인증서를 구입하여 해당 인증서를 통해 https 를 적용할 수 있습니다.
공개키를 사용하는 SSL 인증서
홈쇼핑 회사를 예로 들어보자면,
1. 회사에서 CA에 사용료를 지불하고 인증서를 구입할 때 홈쇼핑 서비스 도메인, 홈쇼핑 서비스 공개키를 CA에게 제공합니다.
2. CA 기업은 CA의 비공개키를 이용해 홈쇼핑 회사에서 제출한 내용을 암호화 합니다.
3. 우리가 사용하는 크롬과 같은 브라우저는 인가받은 CA의 리스트를 가지고 있습니다. 홈쇼핑 서버에서 전달한 인증서의 CA 리스트가 브라우저 의 CA 리스트에 있다면, 해당 CA 회사의 공개키를 가지고 복화를 합니다. 복호화를 했다는 말은 CA회사의 비공개키로 암호화를 거쳤다는 의미이기에 해당 서비스는 _신뢰할만 하다고 할 수 있습니다.
👉 SSL을 통한 데이터 전송
- 클라이언트가 서버에게 통신을 할 때 현재 사용할 수 있는 암호화 방식을 알려줍니다.
- 서버는 클라이언트에게 후보군의 암호화 방식 중 한가지를 선택해 인증서에 랜덤데이터를 담아 클라이언트에게 보냅니다.
- 클라이언트는 앞서 말한 CA 인증을 거쳐 신뢰성 검증을 합니다. 서버측에서 보낸 랜덤 데이터와 클라이언트의 랜덤 데이터를 조합해 pre master secret 키를 생성합니다.
- 앞서 보낸 인증서에 담겨있던 서버측 공개키를 사용해 클라이언트는 pre master secret 키를 암호화 하여 서버측으로 보냅니다.
- 서버는 비공개키를 사용해 클라이언트 쪽에서 공개키로 암호화 했던 pre master key를 복호화 하여 값을 추출해냅니다. 이 단계까지 오면 클라이언트와 서버는 모두 pre master secret값을 공유하게 됩니다.
- 서버는 pre master secret 값을 master secret 값으로 바꾼 후 session key를 생성합니다. 이 session key는 향후 서버와 클라이언트가 주고받는 데이터를 주고받는데 있어서 대칭키가 됩니다.
👉 좀 복잡한 것 같은데요?
대칭키 방식과 비 대칭키 방식을 모두 사용하는 이유는 대칭키 방식이 비 대칭 방식보다 적은 오버헤드를 발생하기 대문입니다. 매번 정보를 주고 받는데 비대칭키를 이용해 인증을 거쳐야 한다면 서버에 많은 오버헤드가 몰립니다.
하지만 대칭키만 이용한다면 중간에 탈취 당했을 경우 보안에 큰 위협이 될 수 있기에
session key를 만들기 전 클라이언트의 pre master secret 키를 서버가 복호화 할때는 비공개키를 사용하고, session key를 만든 이후에는 대칭키를 사용해 데이터를 주고 받게 됩니다.
👉 그림으로 정리해볼까요
함께보면 좋은 글
What Happens in a TLS HandShake?
All about SSL Cryptography
