HTTPS 및 HTTP 엄격한 전송 보안으로 혼란을 야기하는 악의적인 중개자

인터넷이라는 거대한 연속된 관을 통해 흐르는 개인 정보의 양을 감안할 때 암호화는 우리가 약간 무시할 수 있거나 무시해야 하는 것이 아닙니다. 최신 브라우저는 전송 중인 사용자 데이터를 안전하게 보호하는 데 사용할 수 있는 여러 메커니즘을 제공합니다. 보안 쿠키와 Strict Transport Security가 가장 중요한 두 가지 메커니즘입니다. 이를 통해 사용자를 원활하게 보호하고 연결을 HTTPS로 업그레이드하며 사용자 데이터가 투명하게 전송되지 않도록 보장할 수 있습니다.

Shorts가 중요한 이유 다음 사항을 고려해 보세요.

암호화되지 않은 HTTP 연결을 통해 웹페이지를 전달하는 것은 길거리에서 처음 본 사람에게 봉투를 개봉하지 않은 채 우체국을 향하는 길을 걷는 사람에게 건네는 것과 거의 비슷합니다. 운이 좋다면 어머니가 직접 그곳까지 데려갈 수도 있고, 올바른 길을 가고 있는 다음 사람에게 물어볼 수도 있습니다. 그 사람도 똑같이 할 수 있습니다.

즉흥적으로 소통하는 대부분의 낯선 사람들은 믿을 만하며, 공개 편지를 훔치거나 변경하지 않습니다. 그러나 편지가 손을 바꾸는 횟수가 많아질수록, 보내는 편지에 완전히 액세스할 수 있는 사람들의 수가 더 많아집니다. 결국 편지의 의도된 수신자가 메일로 무언가를 받을 가능성이 높지만, 처음에 전달한 내용이 동일한지 여부는 미해결 질문입니다. 그 봉투를 봉인했어야 했을지도 몰라...

중개자

좋든 싫든 인터넷 세상은 낯선 사람들의 신뢰성에 의존합니다. 서버는 서로 직접 연결되지 않지만 거대한 전화 게임에서 라우터에서 라우터로 요청과 응답을 전달합니다.

traceroute를 사용하여 이러한 홉이 작동하는 것을 확인할 수 있습니다. 내 컴퓨터에서 HTML5Rocks까지의 경로는 다음과 같습니다.

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

13홉이 나쁘지는 않네요. 하지만 HTTP를 통해 요청을 보내면 각 중간 라우터는 요청 및 서버의 응답에 대한 완전한 액세스 권한을 갖습니다. 모든 데이터는 암호화되지 않은 일반 텍스트로 전송되고 있으며 이러한 중개자는 중간자 역할을 하여 내 데이터를 읽거나 전송 중에 조작할 수 있습니다.

더 큰 문제는 이러한 종류의 가로채기를 사실상 탐지하기가 힘듭니다. 악의적으로 수정된 HTTP 응답은 수신된 데이터가 정확히 전송된 데이터인지 확인할 수 있는 메커니즘이 없으므로 유효한 응답과 정확히 유사합니다. 누군가 웃음 때문에 내 인터넷을 거꾸로 뒤집어 놓으면 운이 좋지 않을 수도 있습니다.

안전 라인인가요?

일반 텍스트 HTTP에서 보안 HTTPS 연결로 전환하면 중개자로부터 최상의 방어를 할 수 있습니다. HTTPS 연결은 데이터가 전송되기 전에 전체 채널을 엔드 투 엔드 암호화하므로 사용자와 대상 간의 머신이 전송 중인 데이터를 읽거나 수정할 수 없습니다.

Chrome의 검색주소창은 연결 상태에 대한 세부정보를 제공합니다.
Chrome의 검색주소창은 연결 상태에 관한 세부정보를 제공합니다.

HTTPS가 제공하는 보안은 공개 및 비공개 암호화 키의 개념을 기반으로 합니다. 자세한 내용은 이 문서의 범위를 벗어나지만 핵심 전제는 매우 간단합니다. 지정된 공개 키로 암호화된 데이터는 해당 비공개 키로 오직 복호화할 수 있다는 것입니다. 브라우저가 HTTPS 핸드셰이크를 시작하여 보안 채널을 만들 때 서버는 인증서를 제공합니다. 서버는 서버에 적절한 비공개 키가 있는지 확인하여 ID를 확인하는 데 필요한 모든 정보를 제공합니다. 이 시점부터의 모든 통신은 요청이 인증된 서버에서 수신되고 응답이 수신되었음을 증명하는 방식으로 암호화됩니다.

따라서 HTTPS를 통해 대화하고 있다고 생각되는 서버와 대화하고 있으며 다른 사람이 유선으로 수신하거나 비트를 섞는 일이 없다는 것을 확인할 수 있습니다. 이러한 종류의 암호화는 웹 보안을 위한 절대적인 전제 조건입니다. 현재 HTTPS를 통해 애플리케이션이 제공되지 않는 경우 공격에 취약합니다. 문제를 해결하세요. Ars Technica에는 무료 인증서 획득 및 설치 가이드가 있습니다. 기술 세부정보를 살펴보시기 바랍니다. 구성은 제공업체마다, 서버마다 다르지만 인증서 요청 프로세스는 어디서나 동일합니다.

보안은 기본

인증서를 요청하고 설치한 후에는 사용자가 해야 할 일들을 확인해야 합니다. 즉, HTTP 리디렉션을 통해 기존 사용자를 HTTPS 연결로 투명하게 이전하고 쿠키가 보안 연결을 통해만 전송되도록 해야 합니다.

이렇게 해 주세요.

사용자가 http://example.com/를 방문하면 적절한 Location 헤더가 포함된 301 Moved Permanently 응답을 전송하여 https://example.com/로 리디렉션합니다.

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

Apache나 Nginx와 같은 서버에서 이러한 종류의 리디렉션을 쉽게 설정할 수 있습니다. 예를 들어 http://example.com/에서 https://example.com/로 리디렉션되는 Nginx 구성은 다음과 같습니다.

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

쿠키를 사용하면 스테이트리스(Stateless) HTTP 프로토콜을 통해 사용자에게 원활한 로그인 환경을 제공할 수 있습니다. 세션 ID와 같은 민감한 정보를 포함하여 쿠키에 저장된 데이터는 모든 요청과 함께 전송되므로 서버는 현재 어떤 사용자에게 응답하고 있는지 파악할 수 있습니다. 사용자가 HTTPS를 통해 사이트에 방문한다는 것이 확인되면 쿠키에 저장된 민감한 정보가 보안 연결을 통해서만 전송되며 절대 전송되지 않도록 해야 합니다.

일반적으로 쿠키를 설정하려면 다음과 같은 HTTP 헤더가 필요합니다.

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

단일 키워드를 추적하여 세션을 보호하기 위한 쿠키 사용을 제한하도록 브라우저에 지시할 수 있습니다.

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

secure 키워드로 설정된 쿠키는 HTTP를 통해 전송되지 않습니다.

열린 창 닫기

HTTPS로의 투명한 리디렉션은 사용자가 사이트에 있는 대부분의 시간 동안 보안 연결을 사용한다는 것을 의미합니다. 하지만 공격에 노출될 기회가 적습니다. 초기 HTTP 연결은 광범위하게 개방되어 SSL 스트리핑 및 관련 공격에 취약합니다. 중간에 있는 사람이 초기 HTTP 요청에 대한 완전한 액세스 권한을 가지고 있다면, 서버와 서버 사이에서 프록시 역할을 하여 서버의 의도와 관계없이 안전하지 않은 HTTP 연결을 유지할 수 있습니다.

브라우저에 HSTS(HTTP Strict Transport Security)를 적용하도록 요청하여 이 공격 클래스의 위험을 완화할 수 있습니다. Strict-Transport-Security HTTP 헤더를 전송하면 브라우저가 네트워크를 터치하지 않고 클라이언트 측에서 HTTP를 HTTPS로 리디렉션하도록 지시합니다 (이는 성능에도 효과적이며 사용자가 하지 않아도 되는 요청이 가장 좋습니다).

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

이 헤더를 지원하는 브라우저 (현재 Firefox, Chrome, Opera: caniuse 세부정보 있음)는 이 특정 사이트가 HTTPS 전용 액세스를 요청했음을 기록합니다. 즉, 사용자가 사이트를 방문하는 방법과 관계없이 HTTPS를 통해 방문한다는 의미입니다. 브라우저에 http://example.com/을 입력해도 HTTP로 연결하지 않고 HTTPS로 연결됩니다. 더 좋은 점은 브라우저가 잘못된 인증서를 감지하면 (서버의 ID를 스푸핑하려고 시도할 가능성이 있음) 사용자가 HTTP를 통해 계속 진행할 수 없다는 것입니다. 전부 아니면 전무라서 매우 우수합니다.

브라우저에서 max-age초(이 예시에서는 약 1개월) 후에 서버의 HSTS 상태가 만료됩니다. 이를 적당한 값으로 설정합니다.

헤더에 includeSubDomains 지시어를 추가하여 출처의 모든 하위 도메인을 보호할 수도 있습니다.

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

안전하게 이동

HTTPS는 보내는 데이터가 의도한 수신자에게 온전히 도달하는지 원격으로 확인할 수 있는 유일한 방법입니다. 지금 바로 사이트와 애플리케이션에 보안 연결을 설정해야 합니다. 이 과정은 상당히 간단하며 고객의 데이터를 안전하게 유지하는 데 도움이 됩니다 암호화된 채널을 확보한 후에는 사용자가 301 HTTP 응답을 전송하여 사이트에 어떻게 방문했는지에 상관없이 사용자를 이 보안 연결로 투명하게 리디렉션해야 합니다. 그런 다음 쿠키를 설정할 때 secure 키워드를 추가하여 모든 사용자의 민감한 세션 정보가 이 보안 연결만 사용하도록 해야 합니다. 이 작업을 모두 수행한 후에는 사용자가 실수로 버스에서 떨어지지 않도록 하세요. 브라우저에서 Strict-Transport-Security 헤더를 전송하여 올바르게 작동하도록 하여 사용자를 보호하세요.

HTTPS를 설정하면 별다른 작업이 필요하지 않으며 사이트와 사용자에게 큰 이점이 있습니다. 노력한 만큼 보람이 있죠.

자료

  • StartSSL은 무료 도메인 인증 인증서를 제공합니다. 이길 수 없죠. 더 높은 수준의 검증으로 발전하는 것이 당연하고 합리적인 가격입니다.
  • SSL 서버 테스트: 서버에 HTTPS를 설정한 후 SSL 실험실의 서버 테스트를 통해 제대로 설정되었는지 확인합니다. 실제로 제대로 운영 중인지 보여주는 상세한 보고서가 제공됩니다.
  • 서버 설정의 기본사항에 관한 자세한 내용은 Ars Technica의 최근 자료 'SSL/TLS로 웹 서버 보안'을 참고하세요.
  • HTTP Strict Transport Security 사양(RFC6797)에서는 Strict-Transport-Security 헤더에 관한 모든 기술 정보를 훑어보는 것이 좋습니다.
  • 제대로 된 작업을 파악한 후 다음 단계로, 특정 인증서를 통해서만 사이트에 도달할 수 있다고 광고할 수 있습니다. IETF에서 Public-Key-Pins 헤더를 통해 이를 실행할 수 있는 작업이 진행 중입니다. 아직 초기 단계이지만 흥미롭고 살펴볼 가치가 있습니다.