HTTPS
HTTPS(HyperText Transfer Protocol Secure)은 이름에서 알 수 있듯, HTTP에 보안기능이 더해진 Protocol입니다.
웹 브라우저와 웹 서버간 안전한 통신을 위해 사용되는 Protocol입니다.
Why?
HTTP는 평문 통신으로, 암호화 되어있지 않은 통신입니다.
때문에 통신을 누군가 가로채는 중간자 공격등에 취약합니다.
공격자는 통신을 가로채기만 한다면, 도청하거나 조작할 수 있습니다.
또한 ARP스푸핑, DNS스푸핑을 통해 사용자가 원하지 않는 도착지로 전달되는 위험이 있습니다.
How?
HTTPS는 SSL/TLS 인증서를 사용한 SSL/TLS 암호화 방식을 사용합니다.
사용자는 인증서를 통해 실제 의도한 서버로 통신을 하는지 확인할 수 있습니다.
또한 암호화된 통신을 통해 공격자가 통신을 가로채더라도 정보를 알 수 없게 만듭니다.
SSL/TLS 암호화 방식에는 데이터를 암호화 하기위해 크게 두 가지 암호화 방식을 사용합니다.
- 대칭키: 하나의 키가 존재하며, 해당 키로 암호화 한 데이터는 해당 키로 복호화할 수 있습니다.
- 비대칭키: 공개키, 개인키. 두 종류의 키가 존재합니다.
공개키로 암호화한 데이터는 개인키로만 복호화 할 수 있습니다.
반대로 개인키로 암호화한 데이터는 공개키로안 암호화할 수 있습니다.
TLS/SSL를 사용한 통신 과정
복잡해 보일 수 있지만, 생각보다 간단합니다.
큰 흐름은 다음과 같습니다,
CA를 통해 인증서를 확인하고.
인증서에 들어있는 사이트의 공개키를 통해 Browser와 Site가 통신에 사용할 대칭키를 암호화 하여 안전하게 전달하는 것 입니다.
아래에서 좀 더 자세하게 다루겠습니다.
- Site는 "Site 정보와 Site 공개키"를 CA(인증기관)에 전달하여 인증을 요청합니다.
- CA는 "Site 정보와 Site 공개키"를 "CA의 개인키"를 사용해 암호화 하여 "인증서"를 생성합니다.
- CA는 인증서를 Site에 전송합니다.
- CA는 Browser에 "CA의 공개키"를 전달합니다. Browser는 해당 "CA의 공개키"를 사용해 인증서를 복호화 할 수 있습니다.
- Browser가 Site에 접속을 요청합니다.
- Site는 Browser에 인증서를 전달합니다.
- Browser는 "CA의 공개키"를 사용해 "인증서"를 복호화 하여 "Site의 정보와 Site 공개키"를 얻습니다.
- Browser는 "대칭키"를 생성하고, "Site의 공개키"를 사용해 암호화 하여 이를 Site에 안전하게 전달합니다.
- Site는 "Site의 개인키"를 통해 복호화 하여 "대칭키"를 얻습니다.
- Site와 Browser는 "대칭키"를 사용하 안전하게 통신합니다.
공개키, 대칭키 등 키가 많이 나와서 헷갈릴 수 있습니다.
어떤 키가 어떤 목적으로 사용되었는지를 생각하시며 그리시면 좀 더 잘 이해가 될 것입니다.
공개키로 통신을 하지 않는 이유
대칭키에 비해 계산 속도가 오래 걸리고 느립니다.
때문에 대칭키를 안전하게 전달하는 역할로 사용하고, 실제 통신에서는 대칭키를 사용하여 통신합니다.
AWS에서의 HTTPS
AWS에서도 HTTPS를 사용하여 통신할 수 있습니다.
가장 쉬운 방법은 ACM을 사용하여 TLS/SSL 인증서를 프로비저닝 하는 것 입니다.
ACM은 인증서를 관리하고 프로비저닝 해주는 플랫폼입니다.
인증서를 프로비저닝 한다는 점에서 ACM을 CA라고 오해할 수도 있지만, CA와는 조금 다릅니다.
ACM는 AWS가 관리하는 공인 CA를 통해 인증서를 발급받습니다.
때문에 CA라기 보다는 CA기능을 사용하는 인증서 관리 플랫폼입니다.
