HTTP는 클라이언트와 서버가 정보를 텍스트로 주고 받는데 이 때 탈취를 당하면 데이터 유출이 발생한다. 이러한 보안 취약점을 보완하기 위해 HTTP에 SSL을 추가해 주고 받는 정보를 암호화하하는 HTTPS 프로토콜이 등장했다.
💡 SSL과 TLS
SSL은 웹사이트와 브라우저 사이(또는 두 서버 사이)에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술이다.
TLS(Transport Layer Security)은 SSL의 향상된, 더욱 안전한 버전이다. 하지만 SSL이 더욱 일반적인 용어이기 때문에 보안 인증서를 여전히 SSL이라 부른다.
HTTPS 암호화 방식
공개키의 암호화 방식을 사용하지만 공개키의 단점인 느린 속도를 보완하기 위해 대칭키 방식도 함께 사용한다.
공개키 방식으로 대칭키를 전달하고 공유된 대칭키로 통신한다.
공개키 방식
- A키로 암호화 하면 B키로 복호화 할 수 있다.
- B키로 암호화 하면 A키로 복호화 할 수 있다.
- 둘 중 하나를 비공개키 혹은 개인키라 불리며 이는 자신만 가지고 있고 공개되지 않는다.
- 나머지 하나는 공개키라 불리며 타인에게 제공한다. 공개키는 유출이 되어도 비공개키를 모르면 복호화 할 수 없어 안전하다.
대칭키 방식
- 동일한 키로 암호화, 복호화가 가능하다.
- 대칭키는 매번 랜덤으로 생성되어 누출되어도 다음에 사용할 때는 다른 키가 사용되어 안전하다.
- 공개키보다 빠른 통신이 가능하다.
설명한 SSL방식을 적용하기 위해선 인증서를 발급받아 서버에 적용시켜야한다. 여기서 인증서란 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지를 보장하는 역할을 한다.
이러한 인증서를 발급하는 기관을 CA(Certificate authority)라고 부른다. 공인인증기관의 경우 브라우저는 이미 CA 리스트와 각 CA 공개키를 알고 있다.
HTTPS 통신 흐름
- 애플리케이션 서버를 만드는 기업은 HTTPS를 적용하기 위해 공개키, 개인키를 만든다.
- 그 후 신뢰 가능한 CA기업을 선택해 해당 기업에게 서버의 공개키 관리를 목적으로 계약하고 돈을 지불한다.
- 계약한 CA기업은 CA기업만의 공개키와 개인키가 있다.
CA기업은 CA기업 이름
, 서버 공개키
, 공개키 암호화 방법
등의 정보를 담은 인증서를 만들고, 인증서를 CA기업의 개인키로 암호화해서 서버에게 제공한다.
- 서버는 암호화된 인증서를 갖고 서버 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면 암호화된 인증서를 클라이언트에게 전달한다.
- 만약 클라이언트가 서버로 index.html 파일을 요청하면 HTTPS 요청이 아니기 때문에 CA기업이 서버의 정보를 CA기업의 개인키로 암호화한 인증서를 받게된다.
- 중요⭐) 세계적으로 신뢰할 수 있는 CA기업의 공개키는 브라우저가 이미 알고 있다.
- 브라우저가 CA기업 리스트를 탐색하며 인증서에 적혀있는 CA기업의 이름과 같다면 해당 CA기업의 공개키를 이미 알고 있는 브라우저는 해독해서 서버의 공개키를 얻는다.
- 이제부터 서버와 통신 시 서버의 공개키로 암호화해서 요청한다.
이렇게만 보면 HTTPS가 무조건 안전해 보이지만 신뢰할 수 없는 CA기업을 통해 인증서를 발급 받거나, 자체적으로 인증서를 발급하는 경우가 있다. 하지만 다행히 이런 경우 브라우저는 HTTPS라도 “주의 요함”과 같은 알림을 준다.
장점
- 보안: 클라이언트와 서버 간에 교환되는 데이터를 암호화하여 안전하게 통신한다.
- 신뢰: 신뢰할 수 있는 인증 기관(CA)에서 발급한 SSL 인증서를 사용한다.
- SEO: Google은 HTTPS를 사용하면 검색 엔진 순위를 높일 수 있다고 발표했다.
단점
- 성능: 암호화와 복호화 처리 시간으로 통신 속도가 느려진다.
- 비용: SSL 인증서를 발급하고 유지하는데 비용이 발생한다.
References
https://rachel-kwak.github.io/2021/03/08/HTTPS.html
https://devdy.tistory.com/14
https://jeong-pro.tistory.com/89
https://www.digicert.com/kr/what-is-ssl-tls-and-https