안녕하세요.
오늘은 HTTPS 통신
에 대해 포스팅 합니다.
HTTPS 통신
은 데이터를 암호화 하여 통신하도록 설계되어 보안적인 요소가 강화된 HTTP 통신
입니다.
HTTPS 통신
은 HTTP 통신
과 다르게 서버가 제공하는 SSL 인증서
라는 요소가 추가되었으며, 이를 통해 클라이언트는 필요한 서버의 정보를 취득하고 신뢰성을 판단합니다.
데이터 암호화
HTTPS 통신
방법에 앞서, 간단하게 데이터 암호화
개념을 살펴보면 좋습니다.
암호화
란 평문을 암호문으로 변경하는것을 의미합니다.
반대로 복호화
는 암호문을 평문으로 변경하는것을 의미합니다.
평문: 사람이 이해할 수 있는 데이터
암호화
는 어떤 특정 데이터를 사용하여 수행하는데, 이 특정 데이터를 암호키
라고 부릅니다.
암호화는 크게 두가지 방식이 있습니다.
- 대칭키 방식
- 공개키 방식
대칭키 방식
대칭키 방식은 말그대로 암호키
가 대칭임을 의미 합니다.
암호화 할때도, 복호화 할때도 똑같은 1개의 암호키
를 사용하는 것이 특징입니다.
통신 하려는 대상 서로가 암호키
를 알고 있으면 매우 유용합니다.
하지만 불특정 다수와 통신을 하기 위한 안전한 암호키
전달이 무척 어렵습니다.
해커가 중간에 암호키
를 취득 해버리면 데이터를 암호화
하는게 의미가 없기 때문입니다.
Q.암호키
도암호화
해서주면 안되나요? A.암호화
를 하기위해서는 무조건 최초로 평문으로된암호키
를 넘겨주어야만 합니다.암호키
를암호화
해버리면 클라이언트는복호화
를 할 수 있는 키를 모르기 때문입니다.
공개키 방식
공개키 방식은 암호키
가 두가지 존재합니다.
- 공개키
- 비공개키(개인키, 비밀키)
대칭키 방식
과는 다르게 암호화
할때 공개키
를 사용했으면 복호화
는 비밀키
를 사용해야 합니다.
반대로, 암호화
할때 비밀키
를 사용했다면 복호화
는 공개키
로만 가능합니다.
공개키 방식의 장점
공개키 방식
은 대칭키 방식
의 키를 안전하게 전달하기 어려운 단점을 어느정도 해소 하였습니다.
서버가 개인키
를 소유하고 있고, 불특정 다수에게 공개키
를 전달합니다.
이때, 해커가 공개키
를 획득 할 수 있고 그로인해 서버가 내려주는 데이터
를 해석은 할 수 있지만 클라이언트에게 공격하지는 못합니다.
예를들어, 서버가 클라이언트에게 A의 장소
를 알려줬습니다. 이때 해커는 공개키
를 취득해 복호화 하여 내용을 읽었고 클라이언트에게 B의 장소
로 속이고 싶습니다.
해커가 데이터를 변경하더라도 서버가 가지고 있는 비밀키
를 알아야 클라이언트가 속을 수 있는 암호문
을 만들 수 있습니다.
해커가 임의로 암호문을 만들어버리면 클라이언트는 공개키
로 복호화에 실패할것이고, 결국 클라이언트에게 공격하지 못하는 상황이 발생합니다.
물론 클라이언트가 서버의 서비스를 이용 못하는건 있습니다. 하지만 공격 받지 않는것이 핵심입니다.
반대로 클라이언트가 서버로 데이터를 보낼 때는 공개키
로 데이터를 암호화 하여 보냅니다.
해커는 공개키
만알고 있기 때문에 클라이언트 데이터를 읽지 못합니다. 왜냐면 공개키 방식
은 공개키
로 암호화
를 하면 비밀키
로만 복호화
를 진행할 수 있기 때문입니다.
정리하자면 공개키 방식
은 클라이언트로 하여금 데이터가 변경되지 않음을 보장할 수 있고 안전하게 데이터를 서버로 보낼 수 있는 장점이 있습니다.
공개키 방식의 단점
하지만 공개키 방식
도 한계가 존재합니다. 클라이언트 → 서버로 데이터를 암호화
해서 보내는건 문제가 되지 않습니다. 해커가 읽지도 못하니깐요.
하지만 서버 → 클라이언트로 보내는 데이터는 해커가 읽을 수 있습니다. 만약 데이터가 민감한 개인 정보같은게 포함되어 있다면 해커가 읽는것만으로도 피해가 생길 수 있기 때문입니다.
또한 공개키 방식
은 대칭키 방식
보다 암-복호화
속도가 느립니다.
SSL 인증서
HTTPS 통신
에서는 서버가 SSL 인증서
를 제공한다고 언급했습니다.
이 SSL 인증서
는 크게 두가지 역할을 수행합니다.
- 서버 본인이 신뢰할 수 있는 서버임을 증명하는 수단.
- 서버가 제공하는
공개키
를 전달.
SSL 인증서
는 서버의 신뢰성을 판단할 수 있는 수단이라 했는데, 다짜고짜 클라이언트에게 SSL 인증서
를 내밀면 신뢰할 수 있을까요?
예를들어, 모르는 사람이 다가와서 나 믿을 수 있는 사람이야 라고 말하면 여러분을 믿을 수 있으신가요?
그렇기에 SSL 인증서
의 신뢰성을 대신 보장하는 제 3자가 존재합니다.
그 3자를 CA(Certificate authority)
혹은 Root Certificate
라 일컫는 기업들입니다.
해당 기업들은 세계적인 기업으로써, 신뢰성이 엄격하게 공인된 기업들만 CA
로써, 참여할 수 있습니다.
이러한 기업은 SSL 인증서
를 신청한 기업들이 신뢰성있는 기업인지 평가한 후 발급을 진행합니다.
CA
기업들은 잘 알려진 기업들로써, HTTPS 통신
을 지원하는 클라이언트(대표적으로 브라우저)들은 CA 리스트
를 보유하고 있습니다. 그렇기에, 클라이언트는 SSL 인증서
를 받은 후 정보를 읽어 CA 리스트
대조를 통해, CA
가 발급한 SSL 인증서
의 유무를 판단하고 신뢰성을 평가합니다.
CA
가 발급하지 않은SSL 인증서
는 클라이언트가 신뢰성을 낮게 평가합니다.
SSL 인증서 암호화
SSL 인증서는 비공개키 방식
으로 암호화
하여 클라이언트에게 전달됩니다.
이때, 암호화
를 수행하는 대상은 서버가 아닌, CA
에서 자체적으로 소요한 비밀키
를 통해 암호화
를 진행합니다.
즉 SSL 인증서
를 서버에서도 변조하여 클라이언트에게 공격할 수 없습니다. 비밀키
를 모르기 때문입니다.
CA
의 공개키
는 이미 널리 알려진 정보로써, 클라이언트가 CA 리스트
와 함께 공개키
도 보유하고 있습니다. 그렇기에 위에 앞서 언급한 공개키 방식
장점을 잘 활용하고 있다고 볼 수 있습니다. SSL 인증서
가 위조되지 않음을 보장받을 수 있기 때문입니다.
SSL 인증서에 포함된 공개키
SSL
인증서엔 공개키
가 포함되어 있는데 이는, CA
의 공개키
가 아닙니다. 서버가 클라이언트와 보안 통신을 하기위해 서버가 직접 생성한 공개키
입니다.
서버가 CA
에게 SSL 인증서
의 발급 신청을 할 때, 몇몇 서버 데이터를 전달하는데 필수적으로 공개키
도 전달이 되어야 합니다.
뒤에 설명할 SSL 통신
에서는 클라이언트가 SSL 인증서
를 통해 서버의 공개키
를 취득하고, 비공개 방식
으로 보안 통신하는 절차가 있기 때문에 필수적으로 필요합니다.
SSL 통신
공개키 방식
으로 통신을 하면, 서버 → 클라이언트로 데이터를 내려줄땐 조금 문제가 될 순 있지만, 어느정도 감안하고 보안 통신 방법으로 사용할 수 있을거 같습니다.
하지만, 큰 단점이 있는데요.
그것은 바로 공개키 방식
은 암호화 복호화 하는 과정이 느리다 라는 것 입니다.
웹통신이 느리면, 문제가 될 수 있기 때문에 SSL 통신
은 상대적으로 빠른 대칭키 방식
으로 메인 통신을 진행합니다.
하지만, 대칭키
는 공격자가 알면 너무나도 쉽게 데이터를 변조하여 대상을 속일 수 있기 때문에 매우 위험합니다. SSL 통신은 어떻게 이런 이슈들을 해결했을까요?
SSL 통신 방법
결론적으로 말하자면, SSL 통신은 공개키 방식
과 대칭키 방식
둘 다 사용합니다.
SSL 통신은 다음의 아이디어를 사용합니다.
공개키 방식
으로 서버와 함께 작성된 대칭키
를 서로에게 전달합니다. 이때 중간 공격자는 서버의 개인키
를 알고있지 않는한 내용을 복호화
하지 못하여 데이터 해독이 불가능 합니다.
이렇게 서로 안전하게 대칭키
가 전달되었다면, 암-복호화
가 빠른 대칭키
로 데이터 통신을 합니다.
SSL 통신 절차
TCP와 같은 연결지향 프로토콜은 크게 아래의 과정을 거칩니다.
- 악수(HandShake)
- 데이터 전송(세션)
- 세션 종료
SSL 통신
도 결국 TCP위에서 동작하므로, 위 과정과 같습니다만, 세부적인 내용이 조금 다릅니다.
SSL 통신
은 TCP의 핸드쉐이크 (SYN
→SYN ACK
→ACK
) 과정이 이루어 진 후에,SSL 통신
이 시작됩니다. (악수 → 데이터 전송 → 세션 종료)
악수(HandShake)
- Client Hello (클라이언트가 서버에 접속합니다. )
- 서버에게 평문 문자열
Client Hello
를 전송합니다.
- 서버에게
대칭키
를 만들 수 있는 랜덤 데이터를 평문으로 전송 합니다.
- 서버에게 평문 문자열
- Server Hello (서버가
Client Hello
를 받은 후, 클라이언트에게 응답합니다.)- 클라이언트에게 평문
Server Hello
를 전송합니다.
- 클라이언트에게
대칭키
를 만들 수 있는 랜덤 데이터를 평문으로 전송합니다.
- 제일 중요한
SSL 인증서
를 전송합니다.
- 클라이언트에게 평문
- 클라이언트의 SSL 인증서 신뢰성 판단
- 서버에게 받은
SSL 인증서
를 보유하고 있는 CA 리스트를 통해복호화
합니다.
복호화
에 성공하였다면, 해당 서버를 신뢰할 수 있다고 판단합니다.
- 서버에게 받은
- 서버에
대칭키
전송 (SSL 핸드쉐이크의 핵심 목적 입니다.)- 클라이언트는 본인이 만든 랜덤 데이터와 서버에서 받은 랜덤 데이터를 이용하여,
대칭키
를 구성합니다.
- 해당 대칭키를
SSL 인증서
에 포함되어 있는 서버공개키
로암호화
하여 서버에게 전송합니다.
- 클라이언트는 본인이 만든 랜덤 데이터와 서버에서 받은 랜덤 데이터를 이용하여,
- 핸드쉐이크 종료
- 클라이언트와 서버가 서로
대칭키
를 안전하게 전달 받은 후, 통신 준비가 되었다는 신호와 함께핸드쉐이크
가 종료됩니다.
- 클라이언트와 서버가 서로
데이터 전송(세션)
서버와 클라이언트가 데이터를 서로 주고 받고 하는 단계입니다. 서로 안전하게 전달받은 대칭키
를 사용하여, 암-복호화
를 빠르게 진행합니다.
세션종료
데이터 전송
이 끝나면 SSL 통신
이 끝났음을 서로에게 알려줍니다.
오늘 준비한 포스팅은 여기까지 입니다. 읽어주셔서 감사합니다.
'네트워크' 카테고리의 다른 글
[네트워크] REST API (0) | 2021.08.08 |
---|---|
[네트워크] OSI 7계층 (0) | 2021.07.26 |
포스팅이 도움 되셨다면, 커피 한잔 후원해주세요!
더 좋은 포스팅 작성에 큰 힘이 됩니다.
Uploaded by Notion2Tistory v1.1.0