2022. 4. 10. 22:52ㆍTech/Network
- 목차
이 글은 이전에 운영하던 깃 블로그에서 옮겨온 글입니다.
서론
이전 글에서 프로토콜 중 http와 https에 관하여 간단히 알아봤었습니다. 오늘은 그중 https, 정확히는 보안을 어떤 식으로 하는지 간단히 알아보려 합니다.
http는 이름에서도 볼 수 있듯이, 텍스트 데이터를 주고받는다 이야기했습니다. https는 이 텍스트 데이터를 SSL이나 TLS 프로토콜을 한번 거쳐 암호화를 한 뒤 이용하는 구조입니다. 보안의 수준은 웹브라우저 에서의 구현 정확도와 서버 소프트웨어, 암호화 알고리즘에 따라서 천차만별이라고 합니다. 여담으로 SSL이 확산되다가 국제표준기구인 IETF로 넘어가면서 TLS로 이름이 바뀌었다고 하네요. 결국 둘은 같은 거라고 봐도 무방할 듯싶습니다.
SSL / TLS
SSL과 TLS 참으로 자주 나오는 녀석입니다. 이 둘은 같은 거라고 봐도 무방하기 때문에 이후 SSL로 통합해서 이야기하겠습니다.
SSL또한 프로토콜의 일종으로 Secure Sockets Layer의 약자입니다. 데이터를 안전하게 전송하기 위한 통신 규약(프로토콜)을 지칭합니다. 사실 SSL은 https 만을 위한 게 아닙니다. 원격에 있는 파일을 주고받는 데 사용되는 프로토콜인 FTP에 SSL이 더해지면 SFTP가 되듯이, 결국 보안을 위한 독립적인 역할을 해줍니다.
각설하고 SSL이 어떤 식으로 데이터를 암호화하는지 보도록 하겠습니. 참고로 암호화 알고리즘이 아닌, 암호화 방식에 관하여 알아볼 것입니다.
첫번째로 대칭키 방식이 있습니다. 키(key)라고 하면, 데이터를 암호화하는 데 사용되는 비밀번호라고 생각하면 됩니다. 처음 암호화하는 데 사용된 키와 동일한 키로 복호화(암호를 푸는 것) 하는 것을 같은 키를 사용(대칭)한다 하여 '대칭키'라고 부릅니다. 즉, 암호화를 0000으로 했다면 복호화 또한 0000으로 하게 되는 것이죠.
음… 그런데 이것은 조금 위험하지 않을까요? 배포할 때 결국 키도 같이 배포해야 하는데, 암호화하는 키가 배포하려던 사람 이외에도 노출이 되면… 으 상상을 하지 말도록 하죠.
두번째로 알아볼게 공개키 방식입니다. 대칭키가 암호화 키와 복호화 키가 같았다는 것과는 다르게 공개키 방식은 암호화 키와 복호화 키가 서로 다릅니다. 여기서 암호화 키를 '개인키(Private key)', 복호화하기 위하여 제공하는 키를 '공개키(Public key)'라고 합니다. 방식은 A라는 키로 암호화한 것은 B키로 복호화하고, B키로 암호화한 것은 A키로 복호화하는 식으로 운용됩니다. 디지털 인증서에는 공개키로 이용될 키를 함께 배포합니다.
이 설명을 보고 "음? 뭐야 결국 공개키도 노출 되면 위험한 거는 마찬가지 아닌가?"라고 생각할 수 있습니다. 위험한 포인트가 다릅니다. 키 자체가 노출되는 게 문제가 아니라, 이 키를 이용하여 엉뚱한 데이터를 암호화해서 배포하면 위험하다는 것이죠.
예를 들어 바이러스같은걸 암호화해서 배포해서 복호화하여 사용하면… 이게 제작자가 배포한 건지 제삼자가 뿌린 건지 모르게 됩니다. 즉, 공개키 방식은 암호화뿐 아니라 데이터 제공자의 신분도 보장해주는 것입니다. 공개키를 이용해 복호화했다는 것은 제작자만 가지고 있는 개인키로 암호화를 했다는 것이니까 말이죠.
SSL 인증서
위에서 데이터 제공자의 신분을 보장한다는 말을 했다. 이 신분을 보장해주는 게 디지털 서명이다. 이 디지털 서명은 서비스 제공업체와는 다른 서드파티 기업인 CA 기업들이 해준다. CA(Certificate Authority) 혹은 Root Certificate 이라고도 하며 디지털 인증서를 제공하는 보증된 기업들을 말한다.
위는 디지털 인증서의 동작방식의 예시입니다. 결국 CA 기업 중 하나에서 인증서를 사서 배포해야 한다는 것입니다. 이러한 CA 사들은 브라우저들이 이미 알고 있어 보증을 해줍니다.(물론 인증된 CA사 일 경우)
인증 안된 ssl 인증서를 사용하면 위 이미지처럼 x 표시가 뜹니다. 가끔 특정 웹페이지에 접근할 때 인증되지 않은 사이트이라느니 위험할 수 있다느니, 분명 https 사이트인데도 뜨는 곳은 위와 같은 이유입니다. 브라우저가 해당 인증서를 배포한 회사를 몰라서 인 거죠.
SSL 동작 방식
SSL이 동작하는 방식은 Handshake -> Session -> Session end의 과정을 거칩니다.
Handshake
우리말로 악수를 뜻 합니다. 악수를 하는 주목적이 무엇인가? 인사입니다. 서로가 존재하는지 확인하는 과정이며, 데이터를 주고받을 때도 마찬가지입니다. 주는 쪽이나 받는 쪽이 존재할 테니 말이죠.
데이터를 주고받을 때 어떤 방식을 이용할지를 확인하는 과정이기도 합니다. 서버와 클라이언트가 서로 다른 암호화 방식을 사용할 수도 있기 때문에 서로 알려줍니다. 이때 클라이언트 쪽에서 알려주는걸 'Client Hello', 서버 측에서 알려주는걸 'Sever Hello'라고 합니다. 이름 참 재밌네요.
Client Hello에 관한 응답으로 Sever Hello가 오게 되고, 클라이언트 쪽에서 전달받은 암호화 방식 중 서버는 자신이 사용할 수 있는 방식을 답해줌으로써 어떤 암호화 방식을 사용할지 협상하는 과정이라고 볼 수 있습니다.
이렇게 암호화 방식을 교환하고 나면, 클라이언트는 서버를 신뢰할 수 있는지 판단합니다. 클라이언트 내부의 공개키를 이용하여 CA사의 인증서를 복호화하려는 시도를 하고, 복호화에 성공하면 서버를 신뢰할 수 있게 됩니다. 이때 받은 랜덤 데이터와 클라이언트 내부의 랜덤 데이터를 조합해 pre master secret이라는 키를 만듭니다. 그리고 이키를 클라이언트는 배포받은 공개키로 암호화해 서버에 보내며, 서버는 가지고 있는 개인키로 복호화합니다. 이로써 pre master secret 키를 서버와 클라이언트 모두 공유하게 됨으로써 서로를 신뢰하고 데이터를 주고받기 위한 Handshake가 끝이 납니다.
Session
실제로 데이터를 주고받는 단계입니다. 참고로 이때 데이터를 주고받을 때는 공개키 방식이 아닌 대칭키 방식을 사용한다고 합니다. 이는 공개키 방식 자체가 부하를 많이 줘서라고 하네요. 많은 사람이 접속하는 서버 쪽에서 이러한 부하는 큰 부담이 될 수 있기 때문에, 서로를 확인하는 과정에서는 공개키로 하고 이후 보장된 사이에서는 대칭키로 간단하게 암호화를 해서 통신한다고 합니다. 이러한 대칭키를 session key라고 합니다. 이 session key는 이전 Handshake에서 만들어진 pre master secret 키를 master key로 전환하에 생성한다고 합니다.
Session end
모든 과정의 종료 부분입니다. 이 과정에서 session key를 폐기합니다.
서로 인식하고, 사용할 암호를 전달하고, 데이터 전송하고, 볼일 끝나면 서로에 대한 정보를 파기하는 참으로 깔끔한 관계가 아닐까 싶습니다.
리소스 출처
[그림 1] : 초코몽키의 개발로그, https://wayhome25.github.io/cs/2018/03/11/ssl-https/
[그림 2, 3] : 12bme 개발로그, https://12bme.tistory.com/80
'Tech > Network' 카테고리의 다른 글
| [Network]http(s) 패킷(packet) (0) | 2022.04.10 |
|---|---|
| [Network]프로토콜(Protocol) - http / https (0) | 2022.04.10 |
