웹 서버와 클라이언트 간의 문서를 교환하기 위한 통신 규악
웹에서만 사용하는 프로토콜로 TCP/IP 기반으로 서버와 클라이언트 간의 요청과 응답을 전송한다.
TCP 기반의 통신 방식
비연결 지향
단방향성
: 주소 창에 파라미터가 노출 된다.
ex) www.localhost:8080/search?id=account&password=1234
www.google.com/search?id=abcd
브라우저에서 주소에 대한 캐시가 이루어 지므로, 정보를 얻을 때 사용.
: 주소 창에 파라미터가 노출 되지 않는다.
ex)www.localhost:8080/search
www.google.com/search
주소 창에 사용자의 요청 사항이 노출 되지 않는다.
GET 방식에서는 주소 길이 제한이 있지만 POST는 그보다 길게 사용 가능(제한존재)
브라우저가 주소 캐시를 하지 못 하는 특성이 있다.
:POST와 마찬가지로 BODY에 데이터가 들어 있으며, 주로 업데이트에 사용.
:GET과 마찬가지로 주소에 파라미터가 들어가며, 데이터를 삭제 할 때 사용함.
이러한 문제점을 해결하기 위해 HTTPS가 등장했다.
HTTP 통신하는 소켓 부분을 인터넷 상에서 정보를 암호화하는 SSL(Secure Socket Layer)라는 프로토콜로 대체한 것이다.
HTTP는 TCP와 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.
즉, 하나의 레이어를 더 둔 것이다.
HTTPS의 SSL에서는 대칭키 암호화 방식과 공개키 암호화 방식을 모두 사용한다.
SSL 프로토콜은 Netscape 사에서 웹 서버와 브라우저 사이의 보안을 위해 만들어졌다. CA(Certificate Authority)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다.
애플리케이션 서버를 운영하는 기업은 HTTPS 적용을 위해 공개키와 개인키를 만든다.
신뢰할 수 있는 CA 기업을 선택하고 인증서 생성을 요청한다.
CA는 서버의 공개키, 암호화 방법 등의 정보를 담은 인증서를 만들고 해당 CA의 개인키로 암호화하여 서버에 제공한다.
클라이언트가 SSL로 암호화된 페이지(https://)를 요청시 서버는 인증서를 전송한다.
클라이언트와 SSL로 암호화된 페이지를 요청한다.
서버는 클라이언트에게 인증서를 전송한다.
클라이언트는 인증서가 신용이 있는 CA로부터 서명된 것인지 판단한다. 브라우저는 CA 리스트와 해당 CA의 공개키를 가지고 있다. 공개키를 활용하여 인증서가 복호화가 가능하다면 접속한 사이트가 CA에 의해 검토되었다는 것을 의미한다. 따라서 서버가 신용이 있다고 판단한다. 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것으로 이러한 것을 전자 서명이라고 한다.
클라이언트는 CA의 공개키를 이용해 인증서를 복호화하고 서버의 공개키를 획득한다.
클라이언트는 서버의 공개키를 사용해 랜덤 대칭 암호화키, 데이터 등을 암호화하여 서버로 전송한다.
서버는 자신의 개인키를 이용해 복호화하고 랜덤 대칭 암호화키, 데이터 등을 획득한다.
서버는 랜덤 대칭 암호화키로 클라이언트 요청에 대한 응답을 암호화하여 전송한다.
클라이언트는 랜덤 대칭 암호화키를 이용해 복호화하고 데이터를 이용한다.
인증서에 포함된 내용
서버측 공개키(public key)
공개키 암호화 방법
인증서에 사용한 웹서버의 URL
인증서를 발행한 기관 이름
모든 웹페이지에서 HTTPS를 사용하지 않는다. 이유는 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 많이 필요로 하기 때문이다. 통신할 때 마다 암호화를 하면 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 Request 수가 줄어들게 된다.
따라서 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용해야 한다.