HTTP 의 약점
HTTP 에는 다음과 같은 취약점을 가지고 있다
- 평문(암호화 하지 않은) 통신이기 때문에 도청 가능
- 통신 상대를 확인하지 않기 때문에 위장 가능
- 완전성을 증명할 수 없기 때문에 변조 가능
이는 암호화하지 않은 모든 프로토콜의 공통된 약점이다
도청 가능
HTTP 를 사용한 요청이나 응답 통신 내용은 HTTP 자신을 암호화 하는 기능이 없기 떄문에 통신 전체가 암호화 되지 않는다
암호화 되지 않은 메시지로 HTTP 메시지를 보내게 된다
TCP/IP 는 도청 가능한 네트워크
TCP/IP 구조의 통신 내용은 전부 통신 경로 도중에 엿볼 수 있다
인터넷은 전 세계를 경우하는 네트워크로 되어 있다
어느 서버와 클라이언트가 통신 할 때
통신 경로 상에 있는 네트워크 기기나 케이블, 컴퓨터 등을 전부 자기 자신이 소유하고 있는 일은 없다
통신 내용을 엿볼 수 있다는 것은 암호화되었더라도 마찬가지다
암호화 통신은 메시지 속의 의미는 간파할 수 없을 수도 있겠지만
암호화된 메시지 자체는 볼 수 있다
네트워크 상 흐로고 있는 패킷을 수집하는 것만으로 도청할 수 있다
패킷 캡처나 스니퍼 툴을 사용한다
암호화
도청으로 정보를 지키기 위한 방법으로는 암호화가 있다
통신 암호화
HTTP 에는 암호화 구조는 없지만 SSL 이나 TLS 라는 다른 프로토콜을 조합하여 HTTP 통신 내용을 암호화 할 수 있다
HTTP 에 SSL 을 좋아한 HTTP 를 HTTPS 라고 부른다
콘텐츠 암호화
HTTP 에 암호화 하는 기능이 없기 때문에
HTTP 를 사용해서 운반하는 내용을 암호화 하기도 한다
이 경우, 클라이언트에서 HTTP 메시지를 암호화해서 출력하는 처리가 필요하다
메시지 헤더는 암호화되어 있지 않지만
메시지 바디에 들어가는 콘텐츠를 암호화 한다
콘텐츠의 암호화를 유효하게 하기 위해서는
클라이언트와 서버가 콘텐츠 암호화, 복호화 구조를 가지고 있어야 한다
위장
HTTP 를 사용한 요청이나 응답에는 통신 상대를 확인하지 않는다
정말 URI 에 지정된 호스트인지 아닌지 확인하지 않는다
- 누구나 요청을 할 수 있다
HTTP 에 통신에는 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 요청을 보낼 수 있다
요청이 오면 상대가 누구든지 응답을 반환한다
의미없는 요청도 수신하게 된다
증명서
HTTP 에서는 통신 상태를 확인할 수 없지만
SSL 로 상태를 확인할 수 있다
SSL 은 암호화뿐 아니라 상대를 확인하는 증명서를 제공하고 있다
증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이므로
서버나 클라이언트가 실재한다는 사실을 증명한다
증명서를 위조하는 것은 기술적으로 상당히 어렵다
변조 가능
정보가 정확한지 아닌지 확인할 수 없고
때문에 변조 가능하다
수신한 내용이 보낸 것과 다를 수 있다
HTTP 는 완전성을 증명할 수 없다
요청이나 응답 사이 변조되었다고 하더라도 알 수 없다
요청이나 응답 중간에 가로채 변조하는 것을 중간자 공격이라고 부른다
변조 방지
HTTP 의 완전성을 확인하기 위한 방법은 있지만
확실하고 편리한 방법은 ㅇ벗다
MD5 나 SHA-1 등의 해시 값을 확인하는 방법과
디지털 서명을 확인하는 방법이 있다
HTTP 에서는 이 방법들도 확실히 막을 수는 없다
확실히 하기 위해서는 HTTPS 를 사용할 필요가 있다
SSQL 에는 인증과 암호화, 다이제스트 기능을 제공한다
HTTPS
HTTP 에 암호화, 인증, 안정성 보호를 더한 것이 HTTPS 라고 할 수 있다
HTTPS 는 https:// URI 를 사용한다
SSL
HTTPS 는 HTTP 에 SSL 프로토콜을 덮어쓴 것이라고 볼 수 있다
HTTP 통신을 하는 소켓을 SSL 혹은 TSL 프로토콜로 대체ㅔ하고 있을 뿐이다
보통 HTTP 는 TCP 와 직접 통신하지만 SSL 을 사용하는 경우에 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신하게 된다
공개키 암호화 방식
SSL 은 공개키 암호화 방식을 채택하였다
공개키 암호화 방식은 상호 키를 교환하는 방식이다
현대의 암호는 알고리즘이 공개되어 있고 키를 비밀로 함으로 안정성을 유지한다
암호화, 복호화 시 이 키를 사용한다
키가 없으면 암호를 풀 수 없지만
키만 가지고 있다면 누구라도 암호를 풀 수 있게 된다
공격자가 키를 탈취하게 되면 암호화 자체에 의미가 사라진다
공통키 암호화의 딜레마
암호화와 복호화에 하나의 키를 사용하는 방식을 공통키 암호라고 부른다
공통키 암호화는 암호를 확인할 때 상대에게 키를 넘겨주어야 한다
키를 안전하게 보내야만 암호화를 지킬 숭 ㅣㅆ다
두 개의 키를 사용하는 공개키 암호화
공통키 암호화의 문제를 해결하고자 한 것이 공개키 암호화 방식이다
공개키 암호에는 서로 다른 두 개의 키 페어(쌍)을 사용한다
한 쪽은 비밀키, 한 쪽은 공개키 라고 부른다
비밀키는 노출되면 안되는 키고 공개키는 공개되어도 괜찮다
공개키 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 한다
그리고 암호화된 정보를 받은 상대는 공개키를 이용하여 복호화를 한다
이 방식은 암호를 푸는 비밀키를 통신으로 직접 보내지 않기 때문에
중간에 탈취되어도 문제가 없다
공개키의 정보로 평문을 구하는 것은 매우 어려운 수학적 특징을 갖기 때문에 간단하지 않고
큰 수의 소인수 분해를 고속으로 할 수 있다면 해독이 가능할 수 있다
하이브리드 암호 시스템
HTTPS 하이브리드 암호 시스템을 사용한다
공통키 암호화 공개키 암호 양쪽 성질을 가진 암호 시스템을 사용한다
공개키 암호는 공통기에 비해 안전한 대신 처리 속도가 느리기 떄문에
키를 교환하는 곳에서는 공개키 암호를 사용하고
그 후 통신에서 메시지를 교환할 때는 공통키 암호를 사용한다
증명서
증명서는 공개키가 정확한지 아닌지 증명한다
공개키 암호의 문제점은 공개키가 진짜읹 알 수 없기 때문에
증명서를 사용하여 확인한다
증명서는 인증 기관과 인증 기관의 공개키 증명서를 사용하게 된다
인증기관은 클라이언트와 서버가 모두 신뢰하는 제 3자의 기관이다
서버에서 인증 기관에 공개키를 제공하면 인증 기관은 공개키에 서명을 한 인증서를 발급한다
서버는 인증 기관에 의해 발급된 공개키 인증서를 클라이언트에 보내고
클라이언트는 인증된 공개키를 이용해 공개키 암호로 통신을 한다
인증 기관의 공개키는 안전하게 클라이언트에 전달되어야 한다
통신중에는 안전하기가 어렵기 때문에
많은 브라우저가 주요 인증 기관의 공개키를 내장한 상태로 제품을 내고 있다
EV SSL 증명서
EV SSL 증명서는 조직의 실재를 증명한다
증명서의 역할은 서버가 올바른 통신 상대임을 증명하는 것이지만
상대가 실제로 존재하는 기업인지를 확인하는 역할도 있다
이러한 역할을 하는 인증서를 EV SSL 증명서라고 부른다
세계 표준에 의한 가이드라인에 의해 바랳ㅇ되는 증명서로 엄격한 규정을 따른다
클라이언트를 확인하는 클라이언트 증명서
HTTPS 에서는 클라이언트 증명서도 이용할 수 있다
서버 증명서와 같이 서버가 통신하고 있는 상대에 대한 인증을 할 수 있다
클아이언트는 몇 가지 문제점을 갖는데
클라이언트 증명서의 입수와 배포가 하나다
유저가 클라이언트 증명서를 인스톨 해야하고
유료이기 때문에 유저 수만큼 비용이 들게 된다
안정성이 높지만 인터넷 뱅킹 등 특정 용도로만 사용될 수 밖에 없다
또 다른 문제는 언제나 클아이언트의 실재를 증명할뿐으로 사용자를 증명할 수는 없다
인증 기관
SSL 은 인증 기관을 시노리할 수 있다는 것을 전제로 한다
인증 기관이 잘못 엑세스되어 가짜 증명서가 발행된 사건이 있었다
위장 증명서에 대해 증명서를 무효화 할 수 있지만 발견 후 처리하기 까지의 시간 동안은 대책이 없다
자기 인증 기관 발행 증명서
OpenSSL 등의 소프트웨어를 사용하면 누구나 인증 기관을 구축하여
서버 증명서를 발행할 수 있다
하지만 이 증명서는 인터넷 상에서 증명서의 역할은 할 수 없다
마이너 인증 기관 또한 자기 증명서와 같아질 수 있다
HTTPS 의 구조
HTTPS 에서는 안전한 통신을 위한 구조를 갖고 있다
HTTPS 통신 순서
- 클라이언트가 hello 메시지를 송신하면서 SSL 통신을 시작한다
메시지에는 SSL 버전을 저장하고 암호 스위트(suite)로 불리는 리스트 등이 포함되어 있다 - 서버가 SSL 통신이 가능한 경우 hello 메시지로 응답한다
클라이언트와 같이 SSL 버전과 암호 스위트를 포함한다 서버의 암호 스위트 내용은 클라이언트에서 받은 암호 스위트 내용에서 선택된 것이다 - 서버가 Certificate 메시지를 송신한다 메시지에는 공개키 증명서가 포함되어 있다
- 서버가 hello done 메시지를 송신하여 최초의 SSL 네고시에이션이 끝났음을 통지한다
- SSL 최초 네고시에이션이 종료되면 클라이언트가 Client Key Exchange 메시지로 응답한다
메시지에는 통신을 암호화하는데 사용하는 Pre-Master secret 이 포함되어 있다
3의 공개키 증명서에서 꺼낸 공개키로 암호화되어 있다 - 클라이언트는 Change Cipher Spec 메시지를 송신한다 이 메시지는 이후의 통신을 암호키를 사용하여 진행한다는 것을 나타낸다
- 클라이언트는 Finished 메시지를 송신한다 이 메시지는 접속 전체의 체크 값을 포함하고 있다
네고시에이션이 성공했는지 여부는 서버가 이 메시지를 올바르게 이 메시지를 복호화 할 수 있는지에 따라 결정 된다 - 서버에서 Change Cipher Spec 메시지를 송신한다
- 서버에서 Finished 메시지를 송신한다
- 서버와 클라이언트의 Finished 메시지 교환이 완료되면 SSL 에 의해 접속이 확립된다
통신은 SSL 에 의해서 보호되고 있다 이제부터는 애플리케이션 계층의 프로토콜에 의해 통신한다
-> HTTP 요청을 송신 - 애플리케이션 계층의 프로토콜에 의한 통신으로 HTTP 응답을 송신한다
- 마지막에 클라이언트가 접속을 끊는다 접속을 끊을 경우에는 close_notify 메시지를 송신한다
이후에 TCP FIN 메시지를 보내 TCP 통신을 종료한다
이 흐름에 더해 애플리케이션 계층의 데이터를 송신할 때에는 MAC 이라고 부르는 메시지 다이제스트를 덧붙일 수도 있다
MAC 을 이용해서 변조를 감지할 수 있어 완전성 보호를 실현할 수 있다
SSL 과 TLS
HTTPS 에서는 SSL 과 TLS 라는 두 개의 프로토콜이 사용되고 있다
SSL
HTTPS 의 문제는 SSL 을 사용하면 처리가 늦어지게 된다는 점이다
SSL 통신을 사용하면 통신 속도가 떨어지고 CPU 나 메모리 등의 리소스를 더 사용하게 되어 속도가 느려진다
네트워크의 부하는 HTTP 의 요청/응답 이외에 SSL 에 필요한 통신이 추가되기 때문에
전체적으로 처리해야 할 통신이 증가한다
다른 하나는 SSL 은 반드시 암호화 처리를 하고 있기 때문에 서버나 클라이언트에서는 암호화, 복호화를 위한 계산에 클라이언트의 리소스를 소비하게 된다
느려지는 것에 대한 근원적인 해결 방법은 없기 떄문에 SSL 엑셀레이터라는 하드웨어(appliance 서버)를 사용해서 문제를 해결하기도 한다
SSL 엑셀레이터는 SSL 을 처리하기 위한 전용 하드웨어로 스프트웨어로 SSL 을 처리할 때보다 빠른 계산을 할 수 있다
왜 항상 HTTPS 를 사용하지 않는가?
HTTPS 가 안정하다면 왜 모두 HTTPS 만 사용하지 않는 것일까?
SSL 을 위한 통신 속도와 암호화, 복호화를 위한 리소스를 소비하기 때문이다
또 HTTPS 를 위한 증명서 구입 가격 등이 고려 요소이다