"어떠한 내용을 내가 웬만큼은 이해하고 있다." 라고 말할 정도가 되려면 남에게 설명을 할 수 있는 정도, 즉 발표를 해봐야한다고 생각한다.
멋진 개발자를 꿈 꾸는 친구들에게 가벼운 자유주제 테크톡 스터디를 제안했고, 달에 한번씩 모이기로 하였다.😊
내가 준비한 첫번째 발표주제는!!
HTTPS의 암호화 방식과 Client와 Server는 어떻게 통신할까?
우선 HTTP와 HTTPS의 차이부터 알아보자
HTTP
HTTP는 HyperText Transfer Protocol이라고 하는 Client와 Server가 서로 데이터를 주고 받을 수 있는 통신규약이다.
Client는 Server에게 HTTP요청을 보내고, Server는 Client에게 HTTP응답을 보낸다.
이 둘은 이렇게 HTTP라는 프로토콜을 이용하여 주로 html문서를 주고받는다.
＇
HTTP는 보안을 다루지 않기 때문에 중간에 해커가 들어온다면, 정보가 그대로 넘겨지게 되는것이다.
HTTPS
HTTPS(HyperText Transfer Protocol over Secure Socket Layer)는
HTTP 요청 및 응답을 보내기 전에 "보안" 요소 (암호화)를 추가한 것이다.
그래서 해커가 침입해도 암호화 된 문자만 보이기에 그 안에 담긴 진짜 정보를 바로 알 수 없다.
SSL (TSL)
SSL이란 전송계층에서 사용되는 암호화 기반의 프로토콜이다.
TLS라고 명칭이 바뀌었다는데.. 다들 SSL이라고 많이 부른다
왼쪽 사진과 같이 HTTP 서버에 접속했을 경우, 보안 연결이 되지 않았다는 주의 문구를 많이들 보았을 것이다. 위험하다!!
그래서 SSL 프로토콜 위에서 서버를 돌리면 HTTPS 서버가 되는 것이다.
이 HTTPS 서버에는 자물쇠 모양이 있는데, 펼쳐보면 오른쪽 사진과 같은 인증서들을 볼 수 있다.
SSL인증서는 누가 주는데? → 공인 된 기관 CA에서 발급해준다.
CA인증을 어떻게 받는건데?
그 전에~!~! 먼저 알아야 할 SSL 암호화 방식이 있다
SSL 암호화 방식
대칭키
대칭키는 동일한 키로 암호화와 복호화를 한다.
Ex)
1. A가 B에게 'Hello'라는 문자를 보내고 싶어한다.
2. 해당 문자열을 대칭키로 암호화를 해서 알 수 없는 문자를 만든다.
3. B에게 전송한다.
4. B는 해당 문자를 대칭키로 복호화한다.
5. 'Hello'라는 문자열을 얻는다.비대칭키(공개키)
비대칭키는 공개키라고도 (많이) 불린다.
비대칭키는 한쌍의 공개키와 개인키를 가지고 있다.
공개키는 말 그대로 모든 사람에게 공개되어있는 키이고, 개인키는 자신만 가지고 있다
- 공개키로 암호화하면 → 개인키로 복호화 (보안 목적)
- 개인키로 암호화하면 → 공개키로 복호화 (인증 목적)
왜 이게 인증목적이냐? 비밀스러운 정보를 내 개인키로 암호화 해봤자 내 공개키를 가지고 있는 사람들이 모두 볼 수 있기 때문에 보안목적과는 거리가 멀 것이다
이 암호화 방식을 기억하면서, 이번엔 SSL 발급과정과 SSL 통신과정을 알아보자
SSL 발급과정
왜 중고거래로 치면 구매자는 신뢰가 가는 (사기이력이 없는) 판매자에게 구매하고 싶고, 판매자는 신뢰를 주기 위해 핸드폰 인증, 동네인증, 안전결제 인증 등을 사전에 진행한다.
이 판매자 입장과 같이, Server도 자신이 믿을만한 서버라고! 보안이 철저한 서버라고! 내세울만 한 인증서를 받아야한다.
그 인증서가 바로 SSL 인증서 다
한 회사와 CA기관이 있다.
회사는 CA에게 인증서 서명요청(CSR)에 본인 회사의 '공개키'와 회사 정보들을 작성해서
CA에게 "너네 기관은 신뢰 가능한 기관이라고 알려져 있지! 우리 회사 정보를 보고 적합하다면 너네 개인키로 서명해줘" 라고 요청을 한다.
그럼 이 CA인증기관은 오 그래 제대로 된 회사구나 하고 CA의 '개인키'로 암호화해서 인증서를 발급해준다.
이 과정으로 회사는 인증서를 가질 수 있게 되었다!
근데 왜 인증서가 여러개인가?
인증서체인(Ceriticate Chain)
인증서체인은 최종 ROOT CA의 자체서명 인증서를 받을때까지 반복하는 구조를 말한다
일반적으로 인증서는 3계층으로 이루어진다.
위에서부터 대빵인 루트인증서, 중간인증서(여러개 가능), 서버인증서
위 회사가 이 과정을 한바퀴 돌아서 얻어 낸 인증서가 하단의 서버인증서인 셈이다.
ROOT CA입장에서는 타 CA기관도 민간 기업과 같기때문에 같은 과정을 거쳐 인증서를 받아야한다..(→ 중간인증서)
아무튼, 이제 이 회사(서버)는 드디어 인증서를 얻었다!
이제 Client와 통신 준비를 하기 위해 핸드셰이크과정을 지나야한다.
SSL 통신과정 (Hand Shake)
Hand Shake란 Client와 Server가 서로 신뢰성을 확인하고 약간의 정보를 주고 받는과정을 악수한다고 표현해 붙여진 이름이다.
- [Client Hello] 클라이언트가 랜덤데이터 + 기타 정보들을 가지고 서버에게 전달한다
- [Server Hello] 서버에게 랜덤데이터 + SSL 인증서 + 기타 정보들을 가지고 클라이언트에게 답장한다
- 클라이언트는 서버가 준 인증서가 제대로 된 것인지 확인한다.
클라이언트는 CA리스트를 가지고 있는데, 해당하는 CA의 공개키로 SSL 인증서 복호화를 시도해본다! CA의 개인키로 암호화 한게 맞다면, 공개키로 복호화가 되어야 정상이다.
복호화가 잘 되었네? 진짜 CA에서 검증받은 인증서구나, 통신해도 되겠다 - 처음 주고받았던 랜덤데이터를 조합하여 임시 키를 생성한다.
이 키는 서버만 볼 수 있도록 인증서에 포함되어있는 서버의 공개키로 암호화를 해서 전달~ - 서버는 자신의 개인키로 복호화를 해서 임시키를 얻는다
- 이로써 클라이언트와 서버는 동일한 임시키를 소유하게 되었다. 둘은 일련의 과정을 거쳐 최종적으로 Session키 (대칭키)를 생성한다
이 Session키는 앞으로 둘이 통신을 할 대칭키로 사용하게 된다.
데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려주고, 이 때 통신에서 사용한 대칭키인 Session key는 폐기한다.
이 핸드셰이크 과정은 우리가 브라우저를 방문할 때마다 동작한다
그렇다면 왜? 대칭키와 비대칭키를 혼합해서 사용할까?
이렇게 첫 발표를 마쳤다.
잘못 안 부분이 있다면 지적해주세요😉
Summary
HTTP
- Client와 Server가 서로 데이터를 주고 받을 수 있는 통신규약. 보안을 다루지 않음
HTTPS
- SSL을 사용하는 HTTP 프로토콜의 보안 버전
대칭키
- 동일한 키로 암호화 및 복호화를 한다.
- 비교적 보안성이 떨어진다.
- 암호화,복호화에 드는 비용이 적다
- 빠르다
비대칭키
- 한쌍의 개인키와 공개키로 암호화 및 복호화를 한다.
- 보안성이 좋다.
- 구현하기 어렵고 속도가 비교적 느리다
Ceriticate Chain(인증서 체인)
- 최종적으로 root CA 인증서에서 종료되는 연속적인 CA 인증서로 발행된 일련의 인증서
(인증서 - 중간인증서 - 루트인증서)
Hand Shake
- Client와 Server가 서로 통신을 하기 위해
신뢰성을 확인하고 필요한 정보를 주고받는 과정 (악수)
발표를 하는 것은 생각보다 인형에게 설명하는 것보다 어렵더라🥴🤓
