6일차 - 웹을 안전하게 지켜주는 HTTPS

오늘은 HTTP의 안전을 지켜주는 HTTPS에 대해서 배웠다.

평소에 주소를 보면 http인 경우도 있고 https인 경우도 있었는데 이것들이 무슨 차이가 있는지는 잘 몰랐다.

오늘 https를 배움으로써 궁금증을 해결할 수 있었다.

 

 

 

1. HTTP의 약점

지금까지 HTTP의 동작원리와 기능에 대해 배웠다. 클라이언트와 서버간에 통신을 할 수 있게 해주는 HTTP의 단점이자 약점은 무엇이 있을까?

1) 암호화 하지 않은 통신이기 때문에 다른 사람(통신에 참여하지 않은 사람)이 볼 수 있다.

암호화되어 있지않은 통신에 약점이 존재하는 이유는 TCP/IP 구조의 통신 내용은 전부 통신 경로 도중에 엿볼 수 있기 때문이다. 통신 경로 상에 있는 네트워크 기기나 케이블, 컴퓨터 등은 모두 자신이 소유하고 있지 않기 때문에 누군가가 악의적으로 접근하여 메시지를 엿볼 수 있는 것이다.

이러한 약점을 보완하기 위해 사용하는 것 중 가장 보편화되어 있는 것이 암호화이다.

암호화에는 통신 암호화와 콘텐츠 암호화가 있다.

- 통신 암호화: SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합하여 HTTP의 통신 내용을 암호화 할 수 있다. SSL을 조합한 HTTP 를 HTTPS(HTTP Secure)나 HTTP over SSL이라 부른다.

- 콘텐츠 암호화: 통신하고 있는 콘텐츠의 내용 자체를 암호화 하는 방법이다. 콘텐츠의 암호화를 하기 위해서는 클라이언트와 서버가 암호화나 복호화 구조를 가지고 있어야 하므로 주로 웹 서비스 등에서 이용하는 방법이다.

 

2) 통신 상대를 확인하지 않기 때문에 통신에 참여한 사람인 척 위장하여 참여가 가능하다.

HTTP를 사용하여 통신을 하면 리퀘스트를 받은 서버가 URI에서 지정된 호스트가 맞는지, 리스폰스를 받은 클라이언트가 리퀘스트를 보냈던 클라이언트가 맞는지 확인을 하지않기에 모른다.

이렇기에 누구나 서버에 리퀘스트를 보낼 수 있고 서버는 리퀘스트를 보낸 사람이 누구인지 상관없이 리스폰스를 반환한다.

이렇게 통신 상대를 확인하지 않기 때문에 위장한 웹서버나 클라이언트가 존재하여 문제가 발생 할 수 있고 대량의 리퀘스트를 계속 보내어 서버를 마비시키는 공격에 노출될 수 있는 약점을 가지게 된다.

이러한 약점을 보완하기 위해 상대를 확인하는 증명서를 사용한다.

위에서 언급한 SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공한다.

서버나 클라이언트가 증명서를 확인함으로써 통신 상대가 내가 통신하고자 하는 상대인지 아닌지를 판단할 수 있다.

 

3) 완전성을 증명할 수 없기 때문에 변조가 가능하다.

완전성이란 정보의 정확성을 의미하며 완전성을 증명할 수 없다는 말은 정보가 정확한지 판단할 수 없다는 것이다.

즉, 리퀘스트나 리스폰스를 보내고 상대방이 수신할 때까지 그 사이에 변조가 되어도 변조가 되었다는 것을 알 수가 없다.

이러한 약점을 보완하기 위해서 자주 사용되고 있는 방법은 MD5나 SHA-1 등의 해시 값을 확인하는 방법이나 디지털 서명을 확인하는 방법이다.

하지만 이 방법도 확실하게 완전성을 보장할 수는 없다.

확실히 방지하기위해서는 HTTPS를 사용할 필요가 있다.

SSL은 다이제스트라는 기능을 포함하고 있어 중간에 변조가 된 것을 알아챌 수 있다.

(다이제스트는  메시지(데이터)의 해시값(다이제스트 값)을 계산하여 데이터와 함께 전송하는 방법이다. 중간에 누군가가 패킷을 변조하더라도 다이제스트 값을 확인하면 데이터의 변조 사실을 확인할 수 있습니다.)

 

 

2. HTTPS

앞에서 알아본 HTTP의 약점을 보완하기 위해서는 암호화와 인증, 완전성 보호 같은 구조를 HTTP에 추가할 필요가 있다.

지금부터 알아볼 HTTPS(HTTP Secure)가 HTTP에 암호화, 인증, 완전성 보호 기능을 더한 것이다.

HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라 HTTP 통신을 하는 소켓 부분을 SSL이나 TLS라는 프로토콜로 대체하고 있는 것이다.

SSL에 대해 알아보기 전에 암호화 방식에 대해 알아보자.

SSL에서는 공개키 암호화 방식을 사용하고 있다.

현대에는 암호의 알고리즘이 공개되어 있고 키(key)라는 것을 비밀에 부침으로써 안전성을 유지하여 암호화나 복호화할 때 키를 사용한다.

공개키 암호화 방식 이전에는 공통키 암호화 방식이 존재했다.

공통키 암호화 방식은 암호화와 복호화에 하나의 키를 같이 사용하는 방식으로 암호화에 사용한 키를 상대방에게 넘겨주어야 한다. 이렇게 키를 통신을 통해 넘겨주게 되면 중간에 도청을 하여 키를 빼앗길 수가 있다.

또한, 키를 안전하게 보관해야할 필요성도 생긴다.

이러한 공통키 암호와의 단점을 해결하려고 한 것이 공개키 암호화방식이다.

 

공개키 암호화 방식에서는 서로 다른 두 개의 키 쌍을 사용한다. 하나는 비밀키라고 하고 다른 하나는 공개키라고 한다.

비밀키는 누구에게도 알려져서는 안되는 키이고, 공개키는 누구에게나 알려져도 괜찮은 키이다.

공개키 암호를 사용한 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 진행한다.

암호화된 정보를 받은 상대는 자신의 비밀키를 사용해서 복호화를 진행한다.

이렇게 암호화와 복호화가 진행되면 비밀키를 통신으로 보낼 필요가 없어지고 도청에 의해 키를 빼앗길 일도 없게 된다.

 

HTTPS에서는 공통키 암호와 공개키 암호 방식의 성질을 혼합하여 하이브리드 암호 시스템을 사용한다.

공개키 암호 방식은 공통키 암호 방식보다 안전성은 높지만 처리 속도가 느리다.

그래서 각자의 장점을 살리고자 두 방식을 조합해서 통신을 한다.

통신원리는 키를 교환할 때에는 공개키 암호를 사용하고 이후 통신에서 메시지를 교환할 때에는 공통키 암호를 사용한다.

 

이렇게 SSL을 포함하여 통신에 안전성과 메시지의 완전성을 보장하는 HTTPS에는 SSL을 사용하면 처리가 늦어지게 되는 문제가 있다.

SSL을 사용한 통신이 느려지는 이유는 두 가지가 있다.

1) TCP 접속과 HTTP의 리퀘스트, 리스폰스 이외에 SSL에 필요한 통신이 추가되기 때문에 전체적으로 처리해야 할 통신이 증가하여 통신 속도가 떨어진다.

2) SSL은 반드시 암호화 처리를 하고 있기 때문에 서버나 클라이언트에서는 암호화나 복호화를 위한 계산이 필요하게 되고 이로 인해 CPU나 메모리 등의 리소스를 다량으로 소비함으로써 처리가 느려진다.

 

속도가 느려지는 것은 해결하기 위해서는 SSL 엑설레이터라는 하드웨어 장치를 사용하기도한다.

SSL 엑설레이터는 SSL을 처리하기 위한 전용 하드웨어로 SSL이 처리해야할 일들만 SSL 엑셀레이터에 맡김으로써 부하를 분산하여 속도가 느려지는 것을 어느정도 방지할 수 있다.