HTTP 그리고 HTTPS

들어가기 전에...

클라이언트 서버에게 요청하거나 응답을 받는 것

서버 브라우저로부터 요청을 받거나 응답을 보내는 것

 

HTTP

---

클라이언트 프로그램과 서버 프로그램은 http 메시지를 교환하여 통신한다.

💡 http는 메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의한다.

o

이것이 숫자 0인지, 영어 o인지 한글 ㅇ인지 알려면 어떤 언어로 쓰여졌는지를 알아야 한다.

이현진
06139
010-8724-5697

이것을 봤을 때 각각 이름, 우편번호, 전화번호인 것을 알 수 있는 것은 우리가 정해진 형식을 이미 알고 있기 때문이다.

이처럼 http는 인터넷상 커뮤니케이션에서 사용되는 형식들 중 하나이다. 클라이언트와 서버가 메시지를 교환할 때도 교환한 데이터의 형식을 알아야만 그 데이터를 해석할 수 있다. 서버가 클라이언트에 데이터를 보내면 컴퓨터는 http 형식에 따라 데이터를 해석한다.

 

메시지 교환 정의

http는 다음을 정의한다

1. 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청할 것인가
2. 서버가 클라이언트로 웹 페이지를 어떻게 전송할 것인가

 

메시지 구조 정의

요청 메시지

• method: e.g. get, post, put, delete…
• version: http 프로토콜의 버전을 정의. e.g. http/1.1
• entity body: post 방식에서 사용한다.

응답 메시지

• status code + phrase: 200 ok, 404 not found, 500 server error…

 

웹 캐싱

웹 서버

웹 서버는 클라이언트로부터 http request를 받고 html, css, js, image 등 정적인 정보를 반환한다.

대표적인 웹 서버로는 Nginx, Apache, GWS 등이 있다.

proxy server(= 웹 캐시)

• 클라이언트와 웹 서버 중간에 위치하고 있어 통신을 대신 받아준다.
• 자체 저장 디스크를 가지고 있어 최근 호출된 객체의 사본을 저장 및 보존한다.

forward proxy

• 클라이언트가 웹 서버에 직접 요청하고 응답을 받는 것이 아니라 프록시 서버가 대신 요청한 응답을 클라이언트에 forward 한다.
• forward proxy는 캐싱 기능이 있어서 자주 사용하는 콘텐츠에 대해 빠르게 응답 가능하다.

reverse proxy

• http 요청을 특정 네트워크 또는 서버로 전달하는 역할을 수행하는 서버이다.
• 외부로 오픈되지 않은 내부 서버에 접근할 수 있도록 요청과 응답을 전달한다.

 

동작 과정은 다음과 같다.

1. 브라우저가 프록시 서버와 TCP 연결을 설정하고 프록시 서버에 있는 객체에 대한 http 요청을 보낸다.
2. 프록시 서버는 객체의 사본이 자기에게 저장되어 있는지 확인한다.
3. 만약 저장되어 있다면 브라우저에 http 응답 메시지와 함께 객체를 전송한다.
4. 만약 저장되어 있지 않다면 프록시 서버는 원출처의 서버와 TCP 연결을 설정하고 객체에 대한 http 요청을 보낸다.
5. 원 서버는 프록시 서버로 http 응답 메시지와 함께 객체를 전송하고, 프록시 서버는 객체를 수신한 뒤 자신의 저장장치에 복사본을 저장한다. 이후 http 응답 메시지와 함께 객체의 사본을 브라우저에 전송한다.

 

웹 캐시를 사용하면 다음과 같은 장점이 있다.

1. 클라이언트의 요청에 대한 응답 시간을 줄일 수 있다.그래서 캐시가 요청 객체를 가지고 있다면 클라이언트는 빠르게 객체을 받을 수 있다.
2. 보통 클라이언트와 캐시 사이에는 높은 속도의 연결이 설정되어 있다.
3. 한 기관(e.g. 회사, 대학) 에서 인터넷으로 접속하는 링크상의 웹 트래픽을 줄일 수 있다.
4. 트래픽을 줄이면 기관은 대역폭을 자주 개선하지 않아도 되기 때문에 비용을 줄일 수 있다.
5. 인터넷 전체의 웹 트래픽을 줄임으로써 애플리케이션 성능을 개선한다.

 

HTTP의 문제점

 1. 통신 과정에서 교환하는 정보를 제 3자가 알 수 있다. 

http는 다른 사람도 알아볼 수 있는 형태로 데이터가 전송된다.

또한 TCP/IP 구조의 통신은 전부 통신 경로 상에서 다른 사람이 엿볼 수 있다.

그래서 아이디, 비밀번호와 같이 보안이 중요한 데이터를 전송할 때 문제가 될 수 있다.

이를 해결하기 위해 제 3자가 봤을 때 알아볼 수 없도록 데이터를 암호화해야 한다.

 

 2. 통신 상대를 신뢰할 수 없다. 

http를 사용한 통신은 상대가 누구인지 확인하는 과정이 없다.

그래서 여러 가지 문제가 발생한다.

• 요청을 보낸 웹 서버가 원래 의도한 응답을 보내야 하는 웹 서버인지 확인할 수 없다.
• 응답을 보낸 곳의 클라리언트가 요청을 보낸 클라이언트인지 확인할 수 없다.
• 통신하고 있는 상대가 접근 허가된 상대인지 확인할 수 없다.
• 어디에서 누가 요청했는지 알 수 없다.
• 의미 없는 요청도 수신할 수 있기에 DoS 공격을 방지할 수 없다.

현재 내가 접속한 사이트가 구글일지 교글일지 확신할 수 있을까?

만약 특정 사이트로 위장한 피싱사이트에 접속해서 아이디, 비밀번호처럼 중요한 데이터를 입력하게 된다면 문제가 될 것이다.

그래서 현재 접속한 사이트가 신뢰할 수 있는 사이트인지 확신이 필요하다.

 

 3. 완전성을 증명할 수 없기 때문에 변조가 가능하다. 

완전성이란 정보의 정확성을 의미한다.

클라이언트/서버 측에서 수신한 내용이 송신한 내용과 일치한다는 것을 보장할 수 없다는 의미이다.

요청이나 응답이 전송된 후 중간에 누군가 이것을 변조하더라도 알 수 없다.

이러한 문제점들로 인해 실제로는 http가 아닌 https 방식으로 통신하게 된다!

 

HTTPS

---

💡 https란 SSL/TLS 프로토콜로 암호화하여 통신하는 발전된 형태의 http 프로토콜이다.

간단하게 말해서 http에 보안을 추가한 것이 바로 https 이다.

 

SSL

SSL(Secure Sockets Layer)  보안을 통해 향상된 TCP 버전

TLS(Transport Layer Security)  SSL 버전 3의 약간 변형된 버전

SSL은 TCP를 보호하기 때문에 TCP 상에서 일어나는 어떤 응용 과정에도 사용될 수 있다.

SSL은 소켓을 사용하는 간단한 API를 제공하는데, 이는 TCP의 API와 유사하다.

그래서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.

HTTP가 통신하는 소켓 부분을 SSL/TLS 이라는 프로토콜로 대신하는 것이다.

즉, SSL은 실제로 응용 계층에 존재하지만 개발자 관점에서는 보안 서비스로 강화된 TCP 서비스를 제공하는 프로토콜이라고 할 수 있다.

SSL은 앞에서 말한 http의 문제점을 해결하고 보안을 강화하기 위해 암호화 시스템을 사용한다.

그렇다면 데이터를 대체 어떻게 암호화할 수 있을까?

이때 사용되는 것이 바로 대칭키 / 비대칭키 방식이다.

 

대칭키

• 데이터를 암호화하기 위한 방식 중 하나이다.
• 메시지를 보내는 쪽과 받는 쪽이 같은 암호화-복호화 방식(=키)를 공유한다.
• 대칭키만 노출되지 않는다면 중간에 데이터가 노출된다 하더라도 데이터가 노출될 위험이 없다.

하지만 대칭키를 양쪽이 어떻게 공유할 것인가에 대한 문제가 남아있다.

결국은 대칭키를 어느 한쪽에서 다른 한쪽으로 보내야 하기 때문이다.

대칭키를 보내는 과정에서 누군가가 가로챈다면?

이게 바로 바로 대칭키의 한계이다.

비대칭키

• 대칭키의 한계를 보완하고자 나온 암호화 방식이다.
• 서로 다른 두 개의 키가 암호화-복호화 방식에 사용된다.
• 한 쌍의 키면서 서로 다르기 때문에 비대칭키라고 한다. 공개키 방식이라고 하기도 한다.

A키로 암호화했다면 B키로만 복호화가 가능하다.

B키로 암호화했다면 A키로만 복호화가 가능하다.

 

그렇다면 대체 비대칭키를 어떻게 쓰느냐.

 

서버는 두 키 중 하나를 보관한다. 이것을 비밀키(=개인키)라고 한다.

나머지 키는 대중에게 공개한다. 이를 공개키라고 한다.

사용자(=클라이언트)는 공개키를 가지고 데이터를 암호화하여 서버에 보낸다.

전송 도중에 제 3자가 데이터를 가로채더라도 절대 복호화할 수 없다.

왜냐하면 서버가 가지고 있는 비밀키가 없기 때문이다!

이로써 1번과 3번 문제는 해결되었다.

 

그렇다면 신뢰할 수 있는 사이트인지 판단할 수 있는 방법은 무엇일까?

이 문제 역시 공개키로 해결할 수 있다.

 

네이버로 예를 들어보면,

네이버가 보내는 데이터들은 네이버 서버의 비밀키로 암호화되어 있다.

그래서 네이버 서버의 공개키로 복호화할 수 있는 데이터들은 네이버 서버의 비밀키로 암호화한 데이터들 뿐이다.

그래서 다른 사이트에서 온 데이터는 네이버 공개키로 복호화가 불가능하다.

즉, 복호화 되지 않는 데이터를 보내온다면 그 사이트는 신뢰할 수 없는 사이트인 것이다!

이로써 2번 문제도 해결되었다.

 

그렇다면 공개키가 정품인지는 어떻게 확인할 수 있을까?

이를 대신 해주는 기업들이 존재한다. 바로바로 CA(Certificate Authority) 이다.

크롬, 사파리, 엣지 같은 브라우저에는 CA 목록이 내장되어 있다.

 

브라우저에서 사이트에 접속할 때 이루어지는 일들

 1단계 : TCP Handshake 

일반적인 TCP Handshake 과정이 클라이언트와 서버 간에 이루어진다.

 

 2단계 : 인증서 확인하기 

1. 클라이언트는 서버에게 자신이 지원하는 암호화 알고리즘 목록을 보낸다.
2. 서버는 클라이언트에서 받은 옵션에 따라 사용할 암호와 TLS 버전을 선택한다.
3. 서버가 클라이언트에게 선택 결과와 인증서를 보낸다.
4. 브라우저(=클라이언트)는 내장된 CA 정보를 통해 서버 인증서를 확인한다.
   • CA의 인증을 받은 인증서들은 CA의 비밀키로 암호화되어 있다.
   • 즉, CA의 공개키로 복호화가 가능한 인증서라면 CA의 인증을 받은 인증서라고 할 수 있다.
   • 인증서에는 서버의 공개키가 포함되어 있다.

그렇다면 이후 주고 받는 모든 데이터들은 비대칭키 방식으로 암호화과정을 거칠까?

그렇지 않다!

클라이언트-서버 사이에 주고 받는 모든 데이터들은 비대칭키 방식으로 암호화되지 않는다!

비대칭키 방식은 대칭키 방식에 비해 암호화-복호화 과정에서 사용되는 계산 과정이 훨씬 복잡하고, 컴퓨터에 더 많은 부담을 주게 된다.

따라서 대용량 데이터를 모두 비대칭키 방식으로 주고 받기에는 무리가 있다.

실제로 데이터를 주고 받을 때 대칭키, 비대칭키 방식이 혼합되어 사용된다.

분명 앞에서 대칭키를 주고 받을 때 중간에 제 3자에게 노출될 위험이 있어서 문제가 있다고 하지 않았는가?

그래서 비대칭키 방식으로 대칭키를 암호화하여 교환한다.

 

 3단계 : 키 교환하기 

1. 클라이언트는 TCP Handshake 과정에서 주고 받았던 데이터를 바탕으로 임시 키를 생성한다.
   이 키가 바로 대칭키(=세션키)이다.
2. 대칭키를 서버의 공개키로 암호화하여 서버로 전달한다.
3. 서버는 받은 대칭키를 비밀키로 복호화한다.
4.  

 4단계 : 데이터 교환하기 

1. 클라이언트-서버는 대칭키로 데이터를 암호화-복호화 하여 주고 받는다.

 

추가적으로

비대칭키 방식을 구현하는 여러 알고리즘이 존재하지만 대표적인 것이 RSA이다.

RSA 알고리즘은 공개키 암호화와 거의 동의어로 사용된다.

하지만 오늘날에는 diffie-hellman 알고리즘이 세션키를 교환하는데 더 일반적으로 사용된다.

 

참고

https://www.youtube.com/watch?v=H6lpFRpyl14 

https://www.youtube.com/watch?v=j9QmMEWmcfo 

컴퓨터 네트워킹 하향식 접근 제 7판 p.89~105, p.546~586