HTTP(Hyper Text Transfer Protocol)
- 웹서버와 클라이언트 간의 문서를 교환하기 위한 통신 규약
- TCP/IP 기반으로 서버와 클라이언트 간 요청과 응답을 전송한다
특징
- TCP/IP 기반 통신 방식이다
- 비연결 지향
- 브라우저를 통해 사용자의 요청으로 서버와 접속해 요청에 대한 응답 데이터를 전송하면 연결을 종료한다.
- 자원이 적게 든다는 장점이 있지만 연결을 지속할 수 없기 때문에 추가 요청 시 어떤 사용자가 요청한지 모른다는 단점이 있다.
- 여러 사용자가 요청할 시 구분할 수 없어서 제대로 된 응답 데이터를 전송할 수 없다.
- 쿠키, 세션, 히든 폼 필드 등으로 이를 해결할 수 있음
- 상태가 없는(stateless) 프로토콜이다.
- 즉, 데이터를 주고 받기 위한 각각의 데이터 요청이 서로 독립적으로 관리된다. 이전 데이터의 요청과 다음 데이터의 요청이 서로 관련이 없다.
문제점
- HTTP 는 평문(암호화하지 않은) 통신이기 때문에 도청이 가능하다
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다
- 완전성을 증명할 수 없어서 변조가 가능하다
HTTPS (Hyper Text Transfer Protocol Secure)
- HTTP 통신하는 소켓 부분을 인터넷 상에서 정보를 암호화하는
SSL(Secure Socket Layer, 보안 소켓 계층
을 사용함으로써 HTTP 보안 문제를 해결했다.
- SSL 은 서버와 브라우저 간 암호화된 연결을 만들어준다.
- HTTP 는 TCP 와 통신했지만 HTTPS 에서는 HTTP 가 SSL 과 통신하고 SSL 이 TCP 와 통신한다.
- HTTPS의 SSL 은 대칭키 암호화 방식과 공개키 암호화 방식을 모두 사용한다.
SSL, 보안 소켓 계층
- SSL 은 암호화 기반 인터넷 보안 프로토콜이다. CA(Certification Authority)라 불리는 서드파티로부터 서버와 클라이언트를 인증하는데 사용한다.
연결 과정
- 클라이언트는 서버에게 랜덤 데이터와 암호화 방식 후보들을 보낸다.
- 서버도 클라이언트에게 랜덤 데이터를 보내는데 이 때 클라이언트가 보낸 암호화 방식 후보들 중 선택한 암호화 방식을 같이 보낸다. SSL 인증서도 같이 보낸다.
- 클라이언트는 서버에게 받은 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해 클라이언트에 내장된 CA 리스트를 확인한다. 공인된 CA라면 CA의 공개키로 복호화할 수 있다. (공인된 인증서는 CA의 비밀키로 암호화되어 있기 때문)
- 클라이언트는 1 에서 받은 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합해
pre master key
를 만든다. (세션 단계에서 데이터를 주고 받을 때 암호화 하기 위해서 사용한다. 대칭키이기 때문에 외부로 노출되면 안된다.)
- 임시 키를 인증서에 있는 서버의 공개키로 암호화하고 서버로 이를 전송한다.
- 서버는 암호화된 임시 키를 받아 서버의 비밀키로 임시 키를 복호화한다.
- 클라이언트와 서버는 동일한 임시 키를 공유하게 되고 일련의 과정을 거쳐
master key
를 만들고 이를 통해 session key
를 생성한다.(이로써 session key
를 서버와 클라이언트 모두가 공유하게 됐다.)
session key
로 암호화된 데이터를 주고 받는다 (대칭키 암호화 방식)
- 세션이 종료되면 클라이언트와 서버 모두 세션 키를 폐기한다.
CA, Certification Authority
- 만약, A와 B가 통신하는데 C가 끼어들어서 자신이 A라고 주장한다면 어떨까?
- C가 B에게 자신이 A라며 요청을 보냈을 때, C가 B에게 본인의 공개키를 포함한 메세지를 보내면 B는 당연히 A의 공개키라 생각하고 C의 공개키를 이용해서 응답할 것이다.
- 이처럼 자신이 통신하고자 하는 상대의 실제 공개키를 가지고 있는지 확인할 수 있어야 한다.
- 공개키가 어떤 특정한 통신 개체의 것인지 보증하는 일을 인증기관 (CA, Certification Authroity) 에서 담당하는 것이다. 이들의 신원을 확인하고 인증서를 발행해준다.
- 인증서는 공개키 + 신분확인서 가 결합되어 있다. CA가 인증서에 전자서명을 한다.