https 동작은 브라우저 주소창에서 "https:어쩌구어쩌구"를 쳤을때 이뤄지는 절차보다는 사전에 준비되는 내용들을 먼저 이해하는것이 필요하다는 생각에 정리하였습니다.
그림이나 코드없이 작성된 내용을 순차적으로 천천히 읽어보시면 될 것 같습니다.
client에서 server로 https 통신을 한다고 가정합니다. 뭐.. 이게 사실 대부분이기도 하고요.
우선 미리 알고 넘어가야할 사항들이 몇가지 있습니다. 키, 인증서 그리고 사전준비 사항입니다.
1. 키
1) 공개키, 비밀키
이 둘은 쌍으로 만들어 집니다. 공개키로 암호화된건 비밀키로만 풀 수 있고 비밀키로 암호화된건 공개키로만 풀 수 있는 특징이 있습니다. 그리고 이후 설명하는 모든 단계에서 비밀키는 생성한 server에서 절대 외부로 알려지지 않습니다. 그래서 비밀키죠^^. 외부에 공유하거나 보여주는 건 공개키입니다.
2) 대칭키
실제 여러분이 주고받는 데이터를 암호화/복호화에 사용하는 키입니다. 보통은 이걸 많은 분들이 오해하시는데요. 공개키-비밀키를 사용하는 목적은 바로 이 대칭키를 client와 server간에 안전하게 공유하는 용도입니다. 여러분이 실제 주고 받고자 하는 정보들은 공개키-비밀키로 암복호화되는것이 아니고 대칭키로 이루어 집니다.
2. 인증서
인증서란 "내(client)가 server에 접속할때 내가 알고있는 그 server임을 믿도록 해주는 문서/자료"입니다. 그런데 그걸 어떻게 믿지? 하는 의문이 있을 수 있습니다. 그래서 우리는 기술적, 제도적으로 2가지 장치를 마련했는데요. 첫째는 "인증서" 자체는 위변조되면 이를 감지하고 거절되도록 수학적/이론적 배경(수학자분들 수고하셨습니다.)하에 만들어 졌고요, 둘째, 인증서를 만드는 기관들은 그 인증서에 대해 잘 보관/관리하도록 법적책임을 지도록 했습니다.(국회의원분들 잘 하신건가요? ^^) 이 2가지 정도면 믿을만(?)하다고 사회적으로 합의를 한거죠.
그래서 인증서를 발급해주는 기관이 법적 책임있는 공식 기관이면 "공인인증서"가 되는것이고 나만 쓸 목적으로 스스로 인증서를 만들면 "사설인증서"가 되는 것입니다. 짐작하시겠지만 사설인증서를 사용했는데 그 인증서가 유출되서 사고(?)나면 본인 책임입니다^^. 여러분이 내는 공인인증서 발급비용은 일종의 보험료로 생각하시면 됩니다.
3. https 통신전 준비 사항
1) server는 자신이 사용할 공개키-비밀키 쌍을 미리 만들어 보관합니다.
2) server는 "서버 인증서"를 미리 발급받아서 보관하고 있습니다.
서버인증서는 공인인증기관 또는 사설인증기관이 "서버정보+서버공개키"를 "인증기관의 비밀키로 암호화"해서 발급합니다. 비밀키로 암호화했으니 나중에 공개키로 풀 수 있는거죠!
3) client는 자신의 비밀영역(인증서보관 공간)에 "인증서발급기관의 공개키"를 보관하고 있습니다.
유의할 점은 접속하려는 server의 공개키가 아니고 "server 인증서를 발급한 기관의 공개키"입니다.
다만, 다행인건 해당 공개키는 OS개발사, 브라우저 개발사 알아서 잘 보관하고 있으니 별 신경 안쓰셔도 돱니다. 즉, MS(windows, edge), Apple(macos, ios, safari), Google(android, chrome)이 공인인증서 발급기관들과 잘 얘기해서 발급받아 관리하고 있다는 얘기죠. 문제는 사설인증서인데요, 사설인증서는 사설인증서를 만든 server의 정보와 공개키(1에서 이미 만들었죠)는 개발자나 사용자가 직접 OS나 브라우저의 인증서보관 저장소에 등록해야 합니다.
자...이젠 준비가 되었습니다. 접속해볼까요.
4. https 접속을 해봅시다.
브라우저 주소창에서 "https://server.com/gogo어쩌구어쩌구"를 치거나 여러분의 스마트폰 앱이 "https api"로 연결합니다.
1) client가 접속하면 server는 자신의 인증서를 client에게 회신합니다.
2) client의 os나 브라우저의 인증서보관 공간에 있는 공개키들 중에서 수신한 인증서와 관련된 공개키를 사용해서 받은 인증서를 복호화 합니다. 복호화가 정상이면 거기에 server의 공개키가 있을겁니다.(3-2에 설명드렸죠)
3) 여기서 client는 앞으로 통신에 사용할 "대칭키"를 생성하고 2)에서 알아낸 server의 공개키로 암호화해서 다시 server로 전송합니다.
4) server는 다시 자신이 비밀키로 수신한 정보를 복호화하면 client가 만든 대칭키가 나옵니다.
5) 자.. 이제 대칭키를 client와 server 모두 갖게 되었으니 이걸 사용해서 데이터를 암호화해서 보내고 복호화해서 사용하면 됩니다.
끝.
보통은 4.의 절차를 따라서 client와 server가 대칭키를 공유하게 된다 정도를 이해하면 될 것 같습니다. 중간에 나오는 준비, 절차,발급 등은 그야말로 단순절차이고 플랫폼(os, browser, app platform, etc)별로 절차가 크게 다르지도 않습니다. 예를들어 "내 linux 웹서버의 공인인증서 발급받기" 이렇게 검색하면 절차들이 나오는데요 "내 linux웹서버"를 "내 macos apache서버", "회사 centos의 API서버"로 바꿔도 공인인증서 발급받아 설치하는 절차들은 다들 유사합니다.
그리고, 왜 이게 안전(?)한 것인지까지 좀 더 이해를 위해서는 수학적 이해가 필요합니다. 소수(primary number) 특히, 엄청 큰 소수가 가지는 수학적 특징을 이해해야 하는데요. 이번 글 범주에서 벋어나기에 관련 wiki를 참조하셨으면 합니다.
참고: RSA 암호화 https://namu.wiki/w/RSA%20%EC%95%94%ED%98%B8%ED%99%94
