HTTP vs HTTPS
HTTP(HyperText Transfer Protocol)
서로 다른 시스템들 사이에서 통신을 주고받게 해주는 가장 기초적인 프로토콜. 서버에서 브라우저로 데이터를 전송해주는 용도로 가장 많이 사용된다.
HTTPS(HyperText Transfer Protocol Secure)
1. 보안
HTTPS의 S는 Secure을 의미한다. 일반 HTTP 프로토콜의 문제는 서버에서 브라우저로 전송되는 정보가 암호화되지 않는다는 것이었다.
HTTPS 프로토콜은 SSL(Secure Socket Layer)/TLS(Transport Layer Security)를 사용함으로써 이 문제를 해결했다. SSL(TLS)은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고 서버 브라우저가 민감한 정보를 주고 받을 때 이것이 도난당하는 것을 막아준다.
SSL(TLS)은 사용자가 사이트에 제공하는 정보를 암호화한다. 이렇게 전송된 데이터는 중간에서 누군가 훔친다고 해도 암호화되어 있기 때문에 해독할 수 없다.
(TLS는 SSL의 개선 버전으로 최신 인증서는 TLS를 사용하지만 편의적으로 SSL 인증서라고 많이 부른다.)
Instead of:
GET /hello.txt
HTTP/1.1 User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en
The attacker sees something like:
t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==
또한 TLS는 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하고, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공한다.
2. SEO 품질
HTTPS로 전환하게 되면 검색엔진 최적화에 있어서도 큰 혜택을 볼 수 있다. 구글이 HTTPS 웹사이트에 가산점을 주기도 하고, 사용자들이 결국에는 가장 안전하다고 생각하는 사이트를 더 많이 방문하기 때문이다.
HTTPS 통신
암호화 방식
HTTPS는 대칭키, 공개키(비대칭키) 암호 방식을 둘 다 사용한다.
대칭키 방식은 암호화와 복호화에 같은 암호 키를 쓰는 방식이다.
공개키 방식은 두 개의 키를 가지는데 키 A를 사용해 암호화를 하면 키 B로 복호화를 할 수 있고, 키 B로 암호화를 하면 키 A로 복호화할 수 있는 방식이다. 이 방식을 이용해 두개의 키 중 하나를 개인키로 해 자신만이 가지고 있고, 나머지를 공개키로 지정해 공개한다.
공개키가 유출이 되어도 공개키를 이용해서는 암호화만 가능하고 복호화는 개인키로만 가능하기 때문에 정보가 안전하다. 또한 이 방식을 사용하면 공개키가 검증이 되었다면 이를 사용해 암호화된 정보의 출처를 검증할 수 있다. (만약 암호화된 정보가 A사의 공개키로 복호화할 수 있다면 그 정보는 A사의 개인키를 사용해 암호화한 정보이다.)
대칭키 암호화 방식은 빠르지만, 키를 공유하는 방식이 언제나 안전해야 하고 서버와 클라이언트 모두 키를 안전히 보관해야 하는 책임이 있다. 비대칭키 암호화 방식은 대칭키 암호화 방식보다 훨씬 보안의 수준이 높지만 느리다.
그렇기 때문에 두 방식을 혼합하여 사용한다. 즉 데이터를 암호화하는 것은 대칭키를 사용해 암호화하고, 대칭키를 교환할 때 비대칭키 암호화 방식을 사용하는 것이다.
CA(Certificate Authority)
클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 보장하는 역할을 하는 민간기업들을 CA 혹은 Root Certificate라고 부른다.
브라우저에는 내부적으로 CA 목록이 내장되어 있는데 그 목록에 포함되어야만 공인된 CA가 될 수 있다. 브라우저는 CA 목록 뿐만 아니라 CA의 공개키도 알고 있다.
(자체적으로 인증서를 발급할 수도 있고 신뢰할 수 없는 CA 기업을 통해 인증서를 발급받을 수도 있는데, 그렇게 되면 브라우저에서는 https여도 '주의 요함', '안전하지 않은 사이트' 등의 알림을 준다.)
HTTPS 통신 흐름
HTTPS는 handshaking 과정에 비대칭키를 써서 인증서(대칭키)를 보내고 이 인증서의 대칭키를 안전하게 받았다면 이후에는 대칭키를 사용해서 전달하게 된다.
클라이언트가 서버에 연결을 요청하면 서버는 클라이언트에게 서버의 대칭키를 보낸다.
그리고 클라이언트가 서버의 SSL 인증서가 신뢰할 수 있는 웹사이트에서 인증받은 것인지 확인한다.
이제 서버가 준 대칭키로 세션 키를 암호화한다. 그 후 암호화 한 텍스트를 서버에 보내게 된다.
그러면 세션 키는 그대로 있고 세션 키를 암호화한 텍스트가 넘어가게 된다.
세션 키를 암호화한 텍스트가 서버로 가면 서버에서는 개인 키로 풀어서 세션 키를 알게 된다.
이렇게 되면 브라우저와 서버가 같은 키를 가지게 되고, 이 이후로는 더이상 공개키로 통신을 할 필요가 없게 된다. 따라서 이 후에는 대칭키 방식으로 동작한다.
데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알리고, 통신에서 사용한 대칭키인 세션키를 폐기한다.
References
https://www.cloudflare.com/learning/ssl/why-is-http-not-secure/
https://dong5854.tistory.com/30
https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/
https://100100e.tistory.com/317
'TIL' 카테고리의 다른 글
[TIL] 22.12.15 HTTP 메서드 활용, 상태코드 (0) | 2022.12.16 |
---|---|
[TIL] 22.12.12 HTTP 메서드 (0) | 2022.12.13 |
[TIL] 22.11.30 HTTP 기본 (0) | 2022.12.01 |
[TIL] 22.11.26 인터넷 네트워크, URI와 웹 브라우저의 요청 흐름 (0) | 2022.11.26 |
[TIL] 22.11.22 SEO 기본 가이드(4) (0) | 2022.11.23 |