HTTP
- 인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 사용하는 통신 규약
HTTP는 텍스트 교환이므로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재한다. → 해당 보안 문제를 해결해주는 프로토콜이 HTTPS이다.
HTTP의 문제점
- HTTP는 평문 통신이기 때문에 도청이 가능하다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
- 완전성을 증명할 수 없기 때문에 변조가 가능하다.
도청이 가능하다?
TCP/IP 구조의 통신은 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신을 해야한다.
보완 방법
- 통신 자체를 암호화
SSL(Secure Socket Layer)orTLS(Transport Layer Security)라는 다른 프토토콜을 조합하여 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를HTTPSorHTTP over SSL이라고 칭한다. - 콘텐츠를 암호화한다. 즉, HTTP를 사용해서 전송하는 내용인 HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화를 거쳐 전송하면 수신 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.
위장이 가능하다?
HTTP 통신은 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 요청을 보낼 수 있다.
IP주소나 포트 등에서 해당 웹 서버에 접근 제한이 없는 경우 요청이 오면 상대가 누구든지 무언가의 응답을 반환한다. 이러한 특징은 여러 문제점을 유발한다.
- 요청을 보낸 곳의 웹 서버가 원래 의도한 응답을 보내야하는 웹 서버인지 확인할 수 없다.
- 응답을 반환한 곳의 클라이언트가 원래 의도한 요청을 보낸 클라이언트인지를 확인할 수 없다.
- 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
- 어디에서 누가 요청 했는지 확인할 수 없다.
- 의미없는 리퀘스트도 수신한다. → DoS 공격을 방지할 수 없다.
보완 방법
SSL 을 사용하여 상대를 확인할 수 있다. SSL 은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3 자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. 한 가지 이점을 더 꼽자면 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.
완정성을 증명할 수 없어 변조가 가능하다?
여기서 완전성이란 정보의 정확성 을 의미한다. 변조가 가능하다는 것은, 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 요청이나 응답이 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 요청이나 응답을 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle) 이라고 부른다.
보완 방법
MD5 , SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다.
SSL 에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다
HTTPS
HTTPS는 암호화와 인증, 완정성 보호를 가지며, 공개키 암호화 방식으로 텍스트를 암호화한다.
- 인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해서 클라이언트와 서버가 자원을 주고 받을 때 사용하는 통신 규약
- HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니다.
- HTTP의 통신을 수행하는 소켓 부분을
SSLorTLS프로토콜로 대체하는 것이다. - HTTP는 TCP와 직접 통신을 하지만, HTTPS에서는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다.
- SSL을 사용한 HTTPS는 암호화와 증명서, 완정성 보호를 이용할 수 있다.
- HTTPS 의 SSL 에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.
모든 웹 페이지에서 HTTPS를 사용해도 되는가?
평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.
HTTPS 통신 흐름
- 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
- 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
CA란? : Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업
- 계약 완료된 CA 기업은 해당 기업의 이름, 서버A 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 서버A에게 제공한다.
- 서버A는 암호화된 인증서를 갖게 되었다. 이제 서버A는 서버A의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.
- 클라이언트가
main.html파일을 달라고 서버A에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA기업이 서버A의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
CA 기업의 공개키는 브라우저가 이미 알고있다. (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)
- 브라우저는 해독한 뒤 서버A 의 공개키를 얻게 되었다.
- 클라이언트가 서버A 와 HandShaking 과정에서 주고받은 난수를 조합하여 pre-master-key(대칭키) 를 생성한 뒤, 서버A의 공개키로 해당 대칭키를 암호화하여 서버로 보냅니다.
- 서버A는 암호화된 대칭키를 자신의 개인키로 복호화 하여 클라이언트와 동일한 대칭키를 획득합니다.
- 이후 클라이언트-서버사이의 통신을 할 때 주고받는 메세지는 이 pre-master-key(대칭키)를 이용하여 암호화, 복호화를 진행합니다.
단, HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA 기업이 아닌 자체 인증서 발급한 경우 등)
