SSL이 어떻게 동작하는지를 알고싶었을 뿐인데, 어느덧 네트워크와 SSL에 관련된 수많은 웹페이지를 펼치고 있는 나를 보며...
SSL의 배경과 전반적인 동작 원리를 정리하고자 다짐하였다.
SSL이 뭐죠?
전송 계층 보안(영어: Transport Layer Security, TLS, 과거 명칭: 보안 소켓 레이어/Secure Sockets Layer, SSL)[1]는 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약이다. 이 규약은 인터넷 같이 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성을 확보해준다.
네? 이게 무슨 말이죠..?
필자는 처음에 해당 정의를 읽고 조용히 나가기 버튼을 눌렀다. (후...)
그런고로 가장 기본적인 배경부터 설명하고자 한다.
SSL로 가는 여정 1. 웹과 HTTP
HTTP(HyperText Transfer Protocol)를 직역하면 문자 데이터 전송 규약이라는 뜻을 가지고 있다.
'사과'라는 단어를 A라는 사람은 '먹는 사과'로만 알고있고, B라는 사람은 '미안할 때 하는 사과'로만 알고있으면 서로 얘기를 원활하게 할 수 있을까?
단어를 서로 다른 뜻으로 알고있다면 의사소통이 힘들어진다.
하루 이용자수가 어마무시한 웹상에서 모두가 다른 방법으로 의사소통을 한다면, 아마 웹은 작동이 불가능해질 것이다.
따라서 이를 방지하기 위해 '~할때는 ~하세요' 라는 통신 규약을 정해두었는데, 이를 HTTP라고 한다.
이런 HTTP는 클라이언트와 서버 사이에 이뤄지는 요청과 응답으로 이루어진다.
사용자(client)가 로그인 버튼을 누르면(요청), 서버(server)는 인증을 하고 로그인한 정보를 보낸다(응답).
참고로 HTTPS(HyperText Transfer Protocol over Secure Socket Layer )는 기존 HTTP 프토토콜에 보안(SSL)을 추가한 것이다.
SSL로 가는 여정 2. 웹과 보안
대체적으로 보안 문제는 HTTP의 요청과 응답 사이의 통신에서 발생한다.
택배를 붙이면 여러 우체국과 집중국을 거쳐 목적지에 도달하듯이,
우리가 서버로 보내는 데이터 또한 여러 경로를 거치는데, 거쳐가는 과정 속에서 데이터를 탈취당할 가능성이 있다.
데이터 탈취를 막기 위해 보안은 더욱 빠르게 발전했다.
사과: 자몽님, 아무리 생각해도 비밀번호를 그대로 전송하는건 중간에 탈취당할 위험성이 너무 큰거같아요.
자몽: 흠.. 그럼 비밀번호를 암호화시키면 어떨까요? '1234'를 '2345'같이 바꿔서 보낸다면 안전할 것 같은데..
1. 비밀번호를 암호화하고, 서로 비밀번호 키를 가지고 있기
사과: 오 그 방법도 좋은데 문제는 양쪽 다 해당 암호를 적용하고 푸는 방법을 알아야 하지 않을까요? 자몽님이 저한테 '2345'라고 보내면, 정작 저는 원래 암호를 모르잖아요.
자몽: 그럼 사과님 말대로 양쪽 모두가 암호를 푸는 '키'를 가지고 있으면 되는 문제인데...
어라 이상하다? 양쪽 다 키를 가지고 있으려면 누군가가 키를 전달해야하는데, 그러면 다시 원론으로 돌아가지 않나요?
2. 키를 2개로 나누어, 암호화키만 공유하기
사과: 아 그럼 이 방법은 어떨까요? 비밀번호에 대해서 암호화만 가능한 키와 해독만 가능한 키를 만드는거에요.
자몽: 엥 그게 무슨소리죠?
사과: 음.. 그니깐, 하나의 키를 쪼개서 암호를 푸는 'A키'와 암호화시키는 'B키'를 따로따로 만들어 두는거에요.
A키는 저만 가지고 있고, B키를 자몽님에게 전달하면, 자몽님이 B키로 '1234'를 암호화시키고 저한테 보내는거죠.
그럼 중간에 탈취당해도 저만 해독가능한 A키를 가지고 있으니깐 안전해지는거죠!!
자몽: 오....(풀썩)
놀랍게도 위에 있는 이야기가 SSL의 핵심 부분이다.
과거에는 단순히 비밀번호 암호화만 이루어졌기에, 해커들은 손쉽게 암호를 복호화할 수 있었다.
하지만 컴퓨터가 발전하며, 암호화는 말도 안되게 복잡해졌으며,
해커들은 포커스를 암호가 아닌 암호 해독키에 눈을 돌리기 시작했다.
암호를 해독하기 위해선 받는 상대도 필연적으로 해독키가 있어야 했으므로, 이런 해독키를 탈취하기 시작한 것이다.
이를 막기 위해 public key와 secret key로 나누어진 방식을 고안하게 되는데 이것이 SSL의 시초이다.
SSL로 가는 여정 3. 대칭키와 비대칭키
앞선 이야기에서 자몽과 사과는 보안을 위해 2가지 방식을 고민했다.
1. 비밀번호를 암호화하고, 서로 비밀번호 키를 가지고 있기 방법은 대칭키의 방식이다.
대칭키는 암호화, 복호화에 사용되는 키가 같기 때문에 대칭키라는 이름이 붙여졌다.
2. 키를 2개로 나누어, 암호화키만 공유하기 방법은 비대칭키의 방식으로, 암호화에 사용하는 키와 복호화에 사용되는 키가 다른 비대칭적인 키를 가진 방식이다.
필자는 처음 이 내용을 듣고 비대칭키의 방식이 도저히 이해가 되지 않았다.
간단한 예로 '1111'을 오른쪽으로 한 칸씩 이동하는 암호화 방식이 적용되면, 복호화는 이와 반대되도록 왼쪽으로 한 칸씩 이동하면 되는데 어떻게 키가 2개로 나눠질수가 있지? 라는 생각을 가지고 있었기 때문이다.
따라서 비대칭키에 대해 조금 더 자세한 정보를 알아보았다.
우선 대표적인 비대칭키 알고리즘에는 RSA 알고리즘이 있는데, 해당 알고리즘을 사용해 암호화 복호화를 직접 수행하며 어떻게 동작하는지 설명하도록 하겠다.
RSA 암호화 방식
1. 준비 과정
준비물: 2개의 소수 p,q와 평문 M
p=3, q=5, M=13
p,q의 곱인 공개키 N 구하기
N = p*q = 3*5 = 15
N의 소수 갯수(φ(N))구하기
φ(N) = (p-1)*(q-1) = 2*4 = 8
단, N이 소수의 곱셈인 경우에만 위 공식 적용됨
1<e<φ(N) 이고 φ(N)과 서로소인 공개키 e 구하기
e = 3
해당 조건에 맞는 e중 아무거나 하나 택
(d*e)modφ(N)=1인비밀키 d 구하기
d = 11
해당 조건에 맞는 d중 아무거나 하나 택
2. 암호화 과정
암호화(공개키 N, e 사용)
C = M^e mod N = 13^3 mod 15 = 7
3. 복호화 과정
복호화(비밀키d 사용)
M = C^d mod N = 7^11 mod 15 = 13
참고: https://bpsecblog.wordpress.com/2016/12/05/amalmot_6/
RSA는 "큰 숫자는 소인수 분해하기에 어렵다"라는 아이디어에서 기반한 암호 알고리즘이다.
따라서, 예시에서는 q,p를 작은 소수로 사용하였지만, 실제로는 매우 큰 소수를 사용하며, 키 값 또한 약 2048 bit 길이 정도로 사용한다고 한다.
현대 컴퓨터는 매우 빨라졌지만, 그만큼 숫자를 키워 소인수를 분해하기에 어렵게 만들어놨으며, 아직까지는 RSA의 방식이 보편적으로 사용되고 있다.(과거 약 92자리의 수를 소인수분하는데 1600대의 컴퓨터로 8개월이 걸렸다고 한 것을 보면 말을 다했다.)
결론적으로, 필자가 궁금해했던 비대칭키의 원리는 공개키를 알아도 '복호화에 꼭 필요한 비밀키를 알지 못하면 해독할 수 없다'라는 사실을 통해 해결하였다.
여기까지 생각하다보면 한 가지 의문점이 생긴다.
나만 해독할 수 있으면, 상대는 나와 통신할 때 어떻게 암호를 해독할까?
이런 의문은 양쪽 모두에게 비대칭키를 하나씩 주어 해결할 수 있다.
준비물: 비대칭키 A, 비대칭키 B
자몽은 A키를 소유하고 있고, 사과는 B 키를 소유하고 있다.
자몽은 공개 키 A를 모두에게 공유하고, 사과는 공개 키 B를 모두에게 공유한다.
이렇게 공유한 A,B 공개 키는 암호화에 사용되고, 자신만이 가지는 비밀 키는 상대방이 보낸 암호를 복호화하는데 사용된다.
SSL로 가는 여정 4. 이상적인 SSL과 현실적인 SSL
지금까지의 상황을 살펴보자.
1. 현대의 암호는 매우 복잡해 뚫기 힘들기에 해커들은 키 탈취를 노림.
2. 기존 암호화 방법인 대칭키 방식은 키 전달 과정에서 취약함.
3. 비대칭키는 비밀 키를 전달하지 않음.
여기까지만 보면 비대칭키는 그야말로 이상적인 보안 방법이라고 할 수 있다.
하지만, 컴퓨터 기술이 발전하며, 사용하는 소수와 키의 값은 점점 커지고 있으며, 이를 개인 컴퓨터에서 암호화, 복호화 하기에는 많은 시간이 소요된다.
따라서 비대칭키는 간단한 예시로서 '네이버 로그인시 15초 이상 소요'와 같은 상황을 유발한다. 아무리 비밀번호가 안전하게 보관된다 하더라도 저렇게 긴 시간을 사용자는 기다려주지 않는다.
따라서 현재 쓰이고 있는 SSL은 이보다 더욱 현실에 맞춘, 비대칭키와 대칭키의 장점을 섞은 암호화 방식을 사용한다.
SSL의 동작 과정을 이해하기 위해선 우선 CA라는 것을 먼저 알아야 한다.
CA는 인증기관이라는 뜻으로 신뢰성이 엄격하게 공인된 기업들만이 CA로 선정받을 수 있다.
성인이 되면 정부로부터 주민등록증을 발급받는 것처럼, 서버는 사이트를 보장하기 위해 CA로부터 인증서를 발급받는다.
여기서 인증서란 서비스의 정보와 서버의 공개키의 정보가 담겨있는 꾸러미를 말한다.
클라이언트와 서버만 존재한다면, 서버에서 서버의 개인키를 탈취당하는 순간 고객의 정보가 모두 노출되기 때문에 이를 방지하고자 중간에서 '이 서버는 안전해요'라고 적힌 인증서를 주는 CA가 만들어졌다.
1. SSL을 위한 준비 과정
우리가 사이트에 접속하기 전 위와 같은 일이 일어난다.
사이트는 자신의 사이트가 안전하다는 것을 증명하기 위해 CA에게 인증서를 발급받는다.
여기서 인증서는 사이트의 정보와 공개키를 CA의 비밀 키(개인 키)로 암호화시킨 것을 말하는데,
이렇게 만들어진 인증서는 사이트에 전달된다.
아까는 비대칭키는 공개 키로 암호화를 하고, 비밀 키로 복호화를 했다.
하지만 여기서 인증서는 비밀 키로 데이터를 암호화 시켰다.
이는 자연스럽게 공개 키로 복호화를 할 수 있다는 뜻이 되는데, 이런 개념은 매우 이상하게 들린다. 누구나 공개 키를 통해 암호를 복호화시킬 수 있기 때문이다.
그럼에도 불구하고 이렇게 사용하는 이유는, 신뢰성을 보장하기 위해서이다. 어떻게 신뢰성을 보장하는지는 다음 단계에서 마저 설명하도록 하겠다.
2. 브라우저가 사이트에 접속했을 때
브라우저가 사이트에 처음 접속하면, 사이트는 CA로부터 발급받은 인증서를 브라우저에게 전달한다.
앞서 브라우저는 CA로부터 공개키를 발급받았고, 지금 사이트로부터 인증서를 전달받았기 때문에,
CA의 비밀 키(개인 키)로 암호화된 인증서를 공개키를 통해 해독할 수 있다.
인증 기관은 무엇보다 신뢰가 중요하기 때문에 유일하게 자신만 암호화의 권한을 가진다.
브라우저는 인증 기관의 공개키를 가지고 암호화된 데이터를 복호화 시킨다.
여기서 복호화가 성공한다는 뜻은,
데이터를 암호화시킨 CA의 비밀 키(개인 키)와 브라우저에 내장되어있는 CA의 공개 키가 한 쌍이라는 뜻이기에 사이트가 정당한 인증서를 발급받아 브라우저에게 전달해주었다는 것이 된다.
즉, 사이트는 CA에 의해 보장받았음을 뜻한다.
3. 브라우저와 사이트의 통신
브라우저는 대칭키를 생성하고, 사이트의 공개 키를 통해 대칭 키를 암호화시켜 전달한다.
이를 전달받은 사이트는 자신의 비밀 키(개인 키)를 통해 암호를 해독해 대칭 키를 알아낸다.
이후, 둘만 아는 대칭키로 암호화와 복호화를 반복하며 통신을 시작한다.
대칭 키 방법을 사용할 때, 해커들은 전달하는 과정을 노려서 대칭키를 탈취하곤 했다.
하지만, SSL을 사용하면 전달 과정에서 데이터를 탈취해도 오직 사이트만이 복호화를 할 수 있기 때문에,
대칭 키를 알아내기 불가능해진다.
SSL로 가는 여정 5. 그래서 SSL이 뭐라고요?
SSL은 인터넷 상에서 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜이다.
다시 한 번 SSL의 전체적인 과정을 되짚어보자면 다음과 같다.
참고: [도난당한 패스워드] 저자: 김인성
서로가 정당한 사용자인지 인증서를 통해 검증하고, 약속된 암호화 알고리즘을 통해 키를 교환시켜 통신을 이어나가는 흐름 자체가 SSL을 이야기하고 있다.
SSL은 현재 버전 업을 하며 TLS(Transport Layer Security)로 명칭이 변경되어 사용되고 있다.
참고: https://www.wolfssl.com/docs/ssltls-protocol-comparisons
SSL로 가는 여정 6. TCP 내에서 SSL의 동작 과정(심화)
네트워크 프로토콜은 보통 5개/7개 계층으로 분류하고는 한다.
참고: https://cloer.tistory.com/10
애플리케이션 계층(응용 계층)은 네트워크 애플리케이션과 애플리케이션 계층 프로토콜이 있는 곳이고, 대표적으로 HTTP가 있다.
클라이언트와 서버 간의 통신은 트랜스포트 계층이 책임지는데, 트랜스포트 계층(전송 계층)은 애플리케이션 계층 메세지를 전송하는 서비스를 제공한다.
SSL/TLS는 응용 계층과 전송 계층 사이에서 동작하는 독립적인 프로토콜이다.
참고: https://m.blog.naver.com/xcripts/70122755291
SSL/TLS는 응용 계층의 HTTP 프로토콜에서 클라이언트의 데이터를 받아 전송 계층으로 보내지기 전 암호화시킨다.
서버는 전송 계층에서 암호화된 데이터를 받아 SSL/TLS 계층에서 데이터를 복호화하여 응용 계층으로 전달한다.
요약하자면, 응용 계층과 전송 계층 사이의 보안을 담당하는게 SSL/TLS 계층이다.
조금 더 자세히 SSL을 파헤쳐보도록 하자.
SSL은 TCP 내에서 레코드 프로토콜을 통해 보안 서비스를 제공하고, 핸드세이크 프로토콜 등을 통해 SSL 동작 관리를 한다. 해당 내용은 https://coding-start.tistory.com/208?category=808814 에 자세한 설명이 있으므로 해당 사이트를 참고하기 바란다.
여기서는 HandShake 프로토콜에 대해 조금 더 자세히 다루고자 한다.
우선, 핸드쉐이크 프로토콜은 암호 알고리즘 결정, 키 분배, 서버 및 클라이언트 인증을 수행하기 위해 사용되는 프로토콜이다.
TCP는 이 핸드쉐이킹을 통해 연결지향적인 특징을 가지며, 신뢰적인 데이터 전달을 제공하는데, 3번의 악수 과정은 다음과 같다.
1. Client->Server : 서버야 내 목소리 잘 들려?
2. Server->Client : 응 클라이언트야. 잘 들려! 내 목소리는?
3. Client->Server : 너 목소리도 잘 들려!
이런 악수 과정을 통해 TCP는 신뢰적인 데이터 전달을 보장한다.
SSL/TLS는 이런 과정 사이에 껴서 암호화 통신을 가능하게 한다.
참고: https://coding-start.tistory.com/208?category=808814
다음은 필자가 어떤 사이트에 접속하며 주고받은 패킷 내용이다.
핸드쉐이킹 과정을 패킷 내용과 함께 어떻게 동작하는지 살펴보도록 하겠다.
| Client Hello Client->Server 통신 시작 알림 |
Client에서 생성한 난수 사용할 TLS 버전 자신이 지원하는 cipher 리스트(암호 알고리즘 리스트) 클라이언트가 생성한 난수 정보 |
 |
| Server Hello Server->Client 지원 가능한 알고리즘 선정 및 전달 |
Server에서 생성한 난수 사용할 SSL버전 cipher 리스트중 하나 선택 |
 |
| Server Key Exchanges Server->Client 인증서(공개키) 전달 |
인증서 |  |
| Certificate Request Client->Server [선택적] 인증서 요청 |
||
| Server Hello Done Server->Client 전달 완료 알림 |
 |
|
| Client Certificate Client->Server [선택적] 인증서(공개키) 전달 |
인증서 | |
| Client Key Exchange Client->Server 서버의 공개키로 비밀키 암호화 전달 |
pre-master-secret(클라, 서버에서 만든 난수 사용해 제작) 서버의 공개키로 암호화 한 비밀키 |
 |
| Client Verify Client->Server 클라이언트 인증서 무결성 검사 |
||
| Change Cipher Spec / Finished Client->Server 암호화 통신 준비 완료 알림 |
||
| Change Cipher Spec / Finished Server->Client 암호화 통신 준비 완료 알림 |
참고: https://run-it.tistory.com/29
이렇게 다소 복잡한 과정을 거쳐 핸드쉐이킹 과정을 종료하고, 이후로는 대칭키를 사용해 클라이언트와 서버가 통신하게 된다.
마치며...
네트워크는 많은 부분들이 유기적으로 연결되어 있어서 하나를 공부하고자 하면 많은 부분도 함께 알아야 하는 것 같다.
이번에는 http와 https의 차이점과 https에 사용되는 SSL이 어떻게 동작하는지 자세히 알아봤다.
나름 수많은 정보를 모으고 공부하는 과정에서 공부하며 많은 것들을 내 것으로 만든 것 같아 뿌듯하다 :)
아마 다음 글은 http가 버전별로 어떤 차이점이 생겼는지를 설명하는 글이 될 것 같다.
※ 혹시라도 글에 오류가 있다면 댓글로 알려주세요. 참고해 글을 수정하도록 하겠습니다.
참고 링크
프로토콜, SSL 설명: https://cloer.tistory.com/10
자세히 설명한 SSL 구성과 통신과정: https://coding-start.tistory.com/208?category=808814
TLS는 어디서 동작하나?: https://crypto.stackexchange.com/questions/53786/why-is-ssl-on-top-of-tcp
자세히 설명한 SSL 동작과정: https://isc9511.tistory.com/47
WireShark를 사용한 SSL 핸드쉐이크의 이해: https://run-it.tistory.com/29
TLS에 관한 매우 자세한 설명: https://blog.daum.net/endlessole/177
이고잉,SSL 통신과정: https://www.youtube.com/watch?v=8R0FUF_t_zk&t=908s