HTTP
- HTTP(Hyper Text Transfer Protocol)란 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜
- HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다
- 하지만 HTTP는 암호화가 되지 않는 평문 데이터를 전송하기 때문에, 제 3자가 정보를 조회할 수 있었다.
- HTTP 의 문제점
- HTTP 는 평문 통신이기 때문에 도청이 가능하다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
- 완전성을 증명할 수 없기 때문에 변조가 가능하다.
- (위 세 가지는 다른 암호화하지 않은 프로토콜에도 공통되는 문제점들이다.)
TCP/IP 는 도청 가능한 네트워크이다.
TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.
보완 방법
- 통신 자체를 암호화
SSL(Secure Socket Layer)orTLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP 의 통신 내용을 암호화할 수 있다. SSL 을 조합한 HTTP 를HTTPS(HTTP Secure)orHTTP over SSL이라고 부른다.
- 콘텐츠를 암호화 말 그대로 HTTP 를 사용해서 운반하는 내용인, HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.
HTTPS
- HTTPS(Hyper Text Transfer Protocol Secure)는 HTTP에 데이터 암호화가 추가된 프로토콜이다.
- 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용한다.
- 대칭키 암호화
- 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
- 키가 노출되면 위험하지만, 연산 속도가 빠름
- 비대칭키 암호화
- 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용
- 키가 노출되어도 비교적 안전하지만, 연산 속도가 느림
- HTTP의 통신하는 소켓 부분을, SSL/TLS 프로토콜로 대치하여 HTTPS → SSL/TLS → TCP 순으로 통신이 일어나게 된다.
- HTTPS는 HTTP보다 추가 리소스를 소비하지만, 하드웨어의 발달로 인해 속도 저하가 거의 일어나지 않으니, 모든 웹 페이지에 HTTPS를 적용하는 방법으로 바뀌어가고 있다.
- HTTPS 연결 과정의 절차
- 클라이언트는 서버로 최초 연결 시도를 함(3way Handshake)
- 서버는 공개키(인증서)를 브라우저에게 넘겨줌
- 브라우저는 인증서의 유효성을 검사하고, 대칭키를 발급
- 브라우저는 대칭키를 보관하며 추가로 서버의 공개키로 대칭키를 암호화하여 서버로 전송
- 서버는 암호화된 대칭키를 개인키로 복화하하여 대칭키를 얻음
- 클라이언트와 서버는 동일한 대칭키를 공유하므로, 데이터를 전달할 때 대칭키로 암호화/복호화를 진행함
→ 참고로, 인증에 쓰이는 서버의 공개키는, 신뢰할 수 있는 인증 기관(CA)에 공개키를 전송하여 인증서를 발급받는다.
Share article
