Security with HTTPS

웹에서 보안은 사용자 보호를 위해 중요한 부분이고 미래에 좋은 API를 사용하려면 TLS를 지원하는 것이 필수가 될 것이다.

보안 용어 소개

HTTPS로 바꿀 때 사이트 운영자가 겪는 어려움 중 하나는 개념적인 것인데 "정확히 무엇이 진행되는가?", "암호화 용어는 무슨 뜻인가?" 등이다. 이번 장에서 이러한 용어를 살펴볼 것이다.

요약

공개키/개인키(Public / Private keys)는 브라우저와 서버 간의 메시지를 사인하고 해독하는 데 사용한다.
certificate authority (CA)는 공개키와 공개 DNS 이름("www.foobar.com"같은)의 연결을 보장해주는 조직이다.
certificate signing request (CSR)는 키를 가진 엔티티에 대한 일부 메타데이터와 공개키를 함께 묶은 데이터 형식이다.

공개키, 개인키 쌍은 무엇인가?

공개/개인키 쌍은 암호화 키, 복호화 키로 사용할 수 있는 아주 큰 수의 쌍으로 전용 수학적 관계를 공유하고 있다. 키 쌍의 가장 일반적인 시스템은 RSA 암호시스템이다. 공개키는 메시지를 암호화하는 데 사용하고 메시지는 대응되는 개인키로만 복호화할 수 있다. 웹서버는 공개적으로 공개키를 알릴 것이고 클라이언트(웹 브라우저 같은) 이 공개키를 당신의 서버와 보안 채널을 구성하는 데 사용할 것이다.

Certificate Authority는 무엇인가?

certification authority (CA)는 공개키와 공개 DNS 명("www.foobar.com"같은)의 연결을 보장하는 기관이다. 예를 들어 클라이언트가 www.foobar.com의 공개키가 이 공개키인지 어떻게 알 수 있는가? 같은 것이다. 일단 이를 알 방법은 없다. CA는 자신만의 암호화 키로 웹사이트의 공개키를 암호학적으로 사인하는 데 사용함으로써 특정 공개키가 특정 사이트의 공개키라는 것을 보장한다. 이 서명은 계산적으로 위조할 가능성이 없다. 브라우저(그 외 클라이언트)는 잘 알려진 CS가 소유한 공개키를 보관하는 신뢰할 수 있는 anchor 저장소(trust anchor sotres)를 유지하고 CS 서명을 암호학적으로 확인하는데 이 공개키를 사용한다.

X.509 certificate는 공개키를 소유한 엔티티에 대한 메타정보와 공개키를 함께 묶은 데이터 형식이다. 웹의 경우 키의 소유자는 사이트 운영자이고 중요한 메타데이터는 웹서버의 DNS 명이다. 클라이언트가 HTTPS 웹서버에 접속했을 때 웹서버는 클라이언트가 확인할 수 있도록 인증서를 제공한다. 클라이언트는 이 인증서가 만료되지 않았고 DNS 명이 클라이언트가 접속하려는 서버의 이름과 일치하는지 알려진 trust anchor CA가 인증서에 서명했는지를 확인한다. 대부분의 경우 CA가 직접 웹서버의 인증서를 사인하지 않는다. 보통은 trust anchor를(사인 중계자나 사인한 사람을) 연결하는 인증서의 체인이 있어서 최종적으로 웹서버가 가진 인증서(최종 엔티티)에 연결된다.

Certificate Signing Request는 무엇인가?

certificate signing request (CSR)는 인증서 같은 데이터 형식으로 키를 소유한 엔티티에 대한 메타데이터와 공개키를 묶어 준다. 하지만 클라이언트는 CSR을 해석하지 않고 CA가 해석한다. 당신의 웹서버 공개키를 보장하는 CS를 찾고 있다면 CA에 CSR을 보내야 한다. CA는 CSR의 정보의 유효성을 검증하고 이를 사용해서 인증서를 생성한다. 그리고 최종 인증서를 당신에게 보내고 이 인증서를 설치하고(보통은 인증서 체인) 개인키는 웹서버에 둔다.

Key와 Certificate Signing Requests 생성하기

이번 장에서는 대부분의 Linux, BSD, Mac OS X에 있는 openssl 커맨드라인 프로그램을 사용해서 개인키/공개키, CSR을 생성한다.

요약

2048비트 RSA 공개, 개인키 쌍을 생성해야 한다.
공개키에 내장된 certificate signing request (CSR) 를 생성한다.
최종 인증이나 인증 체인을 받기 위해 당신의 Cerfticate Authority (CA) 에 CSR을 공유한다.
/etc/ssl (Linux와 Unix)나 IIS가 원하는 곳(윈도우)처럼 웹에서 접근할 수 없는 곳에 최종 인증서를 설치한다.

공개/개인 키 쌍 생성

이 예제에서 2,048비트 RSA 키 쌍을 생성할 것이다. (1,024비트처럼 더 작은 키는 브르트포스 추측 공격을 막을 만하지 않다. 4,096처럼 더 큰 키는 과도하다. 시간이 지남에 따라 키 크기는 계산 비용이 싸짐에 따라 증가할 것이다. 현재는 2,048이 적당하다.)

RSA 키 쌍을 생성하는 명령어는 다음과 같다.

openssl genrsa -out www.example.com.key 2048

다음과 같은 출력이 나온다.

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

CSR 생성하기

이 단계에서 certificate signing request 안에 공개키와 조직과 웹사이트에 대한 정보를 내장시킨다. openssl가 대화식으로 메타데이터에 대해서 물을 것이다.

다음 명령어를 실행한다.

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

다음과 같이 출력된다.

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:Mountain View
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (eg, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

이제 다음 명령어로 CSR이 제대로 되었는지 확인한다.

openssl req -text -in www.example.com.csr -noout

이 응답은 다음과 같이 나올 것이다.

Certificate Request:
  Data:
    Version: 0 (0x0)
    Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
        Public-Key: (2048 bit)
        Modulus:
          00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
          f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
          ...
        Exponent: 65537 (0x10001)
    Attributes:
      a0:00
  Signature Algorithm: sha256WithRSAEncryption
    5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
    2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
    ...

CSR을 CA에 제출하기

어떤 CA를 사용하고자 하냐에 따라 CSR을 CA에 보내는 방법이 다를 것이다. 웹사이트의 형식을 사용한다면 이메일 등으로 보낼 수 있다. 일부 CA는(혹은 그의 리셀러) 일부나 전체 과정을 자동화했을 수도 있다.(일부의 경우에는 키 쌍과 CSR 생성도 포함한다)

CA에 CSR을 보내고 최종 인증서나 인증 체인을 받기 위해 다음 단계를 진행한다.

CA마다 공개키를 보장하는 금액이 다르다.

여러 가지 다른 이름을 포함해서 하나 이상의 DNS 이름(예를 들면 example.com, www.example.com, example.net, and www.example.net 모두나 *.example.com 같은 "와일드카드"이름)에 키를 매핑하는 것도 가능하다.

예를 들어 어떤 CA는 현재 다음의 가격을 제시한다.

표준: $16/연, example.com와 www.example.com에 유효하다.
와일드카드: $150/연, example.com와 *.example.com에 유효하다.

이 가격에서 서브도메인이 9개가 넘는다면 와일드카드 인증서가 더 경제적이다. 그렇지 않으면 하나 이상의 단일 이름 인증서를 살 수 있다.(5개 등 그 이상의 서브도메인이 필요하다면 서버에서 HTTPS를 사용할 때 와일드카드 인증서가 더 편할 수도 있다.)

Note: 와일드카드 인증서는 1 DNS 레이블에만 적용된다는 것을 명심해라 *.example.com의 인증서는 foo.exmaple.com이나 bar.example.com에는 동작하지만 foo.bar.example.com에는 동작하지 않는다.

모든 프론트엔드 서버에서 /etc/ssl(Linux와 Unix)이나 IIS가 설치하는 곳(Windows)처럼 웹에서 접근할 수 없는 곳에 인증서를 복사한다.

서버에 HTTPS 활성화하기

서버에서 HTTPS를 활성화하는 모든 중요한 단계가 준비되었다.

요약

HTTPS를 지원하도록 서버를 설정할 때 Mozilla의 서버 설정도구를 사용해라.
Qualys' handy SSL Server Test로 정기적으로 사이트를 검사하고 최소 A나 A+를 받도록 해라.

이 가이드 에서는...

이번 단계에서 아주 중요한 운영 결정을 해야 한다.

콘텐츠를 제공하는 웹서버의 각 호스트네임마다 구분되는 IP 주소를 전용으로 할당하거나
이름에 기반을 준 버츄얼 호스팅을 사용한다.

호스트네임마다 별도의 IP 주소를 사용한다면 아주 좋다! 쉽게 모든 클라이언트에 HTTP와 HTTPS를 모두 지원할 수 있다.

하지만 대부분의 사이트 운영자는 IP 주소를 아끼고 보통은 더 편리하므로 이름에 기반을 둔 버츄얼 호스팅을 사용한다. Windows XP의 IE와 2.3 이전 버번의 Android는 HTTPS 이름 기반 버츄얼 호스트에 중요한 Server Name Indication(SNI)를 이해하지 못하는 문제가 있다.

SNI를 지원하지 않는 클라이언트가 언젠가는(제발 빨리 좀) 모든 소프트웨어로 교체될 것이다. 요청 로그에서 유저 에이전트를 모니터링해서 모던 소프트웨어를 사용하는 사용자 수가 충분해 졌는지 감시해야 한다. (스레스홀드를 결정할 수 있다. 아마 5% 이하나 1% 이하 일 것이다.)

서버에서 이미 HTTPS 서비스를 가지고 있지 않다면 지금 활성화해라.(HTTP를 HTTPS로 리다이렉트하지 않고... 아래 참고) 구매하고 설치한 인증서를 웹서버가 사용하도록 구성해라. Mozilla의 편리한 설정 생성기가 유용할 것이다.

호스트네임이나 서브도메인이 많다면 올바른 인증서를 각각 사용해야 한다.

Note: 많은 사이트 운영자는 이미 여기서 다루는 단계를 이미 마무리했지만 HTTPS를 HTTP로 리다이렉트하는 하나의 목적으로 사용하는 경우가 많다. 만약 이렇게 하고 있지만 멈추기를 바란다. HTTPS와 HTTP가 자연스럽게 동작하는 방법은 다음 장에서 살펴본다.

Note: 결국은 HTTP 요청을 HTTPS로 리다이렉트하고 HTTP Strict Transport Security (HSTS)를 사용해야 한다. 지금은 이 마이그레이션을 하기에 적당한 상황은 아니다. "HTTP를 HTTPS로 리다이렉트하기"와 "Strict Transport Security와 Secure Cookies를 켜라."를 참고해라.

이제 사이트를 운영하는 동안 Qualys’ handy SSL Server Test로 HTTPS 구성을 확인해봐라 사이트는 A나 A+ 점수가 나와야 하고 등급을 낮추는 모든 것은 버그로 간주해야 한다. (알고리즘이나 프로토콜에 대한 공격이 항상 더 좋아지므로 오늘은 A이고 내일은 B일 수 있다!)

사이트 내부 URL 상대적으로 만들기

이제 사이트에서 HTTP와 HTTPS를 모두 제공하는데 이러면 프로토콜에 상관없이 자연스럽게 동작하게 해야 한다.

요약

사이트 내부 URL와 외부 URL이 프로토콜에 영향을 받지 않도록 해야 한다. 예를 들어 상대 경로를 사용하거나 //example.com/something.js처럼 프로토콜을 유지해야 한다.

이번 가이드에서는

하지만 HTTP 리소스를 가진 페이지를 HTTPS로 제공할 때 혼합 콘텐츠 문제가 발생한다. 브라우저는 HTTPS의 장점을 잃어버릴 수도 있다고 사용자에게 경고할 것이다.

사실 혼합된 콘텐츠를 사용하는 경우(스크립트, 플러그인, CSS, iframe) 브라우저가 로딩하지 않거나 콘텐츠를 전혀 실행하지 않아서 페이지가 깨질 수 있다.

NOTE: HTTP 페이지에 HTTPS 리소스를 포함하는 것은 전혀 문제가 없다.

추가로 사이트에서 다른 페이지를 링크할 때 사용자는 HTTPS에서 HTTP를 다운로드 할 것이다.

http://scheme를 사용하는 정규화되고 사이트 내부 URL을 포함하는 페이지에서 발생한다. 다음과 같은 콘텐츠를

<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>Read this nice <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

다음과 같이 바꾸어야 한다.

<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>Read this nice <a href="//example.com/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

아니면 다음과 같이 바꿀 수도 있다.

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>Read this nice <a href="/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

즉 사이트 내부 URL을 가능한 한 상대적으로 만들어라. 프로토콜에 상대적이든(//example.com으로 시작해서 프로토콜을 생략한) 호스트에 상대적이든(/jquery.js처럼 경로만 사용하는) 상관없다.

NOTE: 이 작업을 직접 하지 말고 스크립트로 해라. 사이트의 콘텐츠가 데이터베이스에 있다면 데이터베이스의 개발 복사본에서 스크립트를 테스트하기 원할 것이다. 사이트의 콘텐츠가 그냥 파일이라면 파일의 개발용 복사본에서 스크립트를 테스트해라. 평소처럼 변경사항이 QA를 통과한 후에만 프로덕션에 변경사항을 적용해라. 사이트에 혼합 콘텐츠가 있는지 탐지하는 Bram van Damme의 스크립트나 그와 비슷한 것을 사용할 수 있다.

NOTE: 다른 사이트에 대한 링크를 추가할 때는(이러한 사이트의 리소스를 포함할 때와는 반대이다) 이러한 사이트의 운영 방식을 제어할 수 없으므로 프로토콜을 변경하지 마라.

NOTE: 대형 사이트에서 자연스럽게 변경하려면 프로토콜에 상대적인 URL을 추천한다. 완전히 HTTPS로 배포할 수 있다고 확신하기 어렵다면 문제가 생길 수 있는 모든 하위 리소스에 HTTPS를 사용하도록 강제해라. HTTPS가 새롭거나 이상하게 느껴질 수도 있고 HTTP 사이트도 여전히 잘 돌아간다고 생각할 수 있는 시기이다. 하지만 시간이 지남에 따라 HTTPS로 완전히 갈아타야 하고 HTTPS만 사용해야 한다.(다음 두 장을 봐라.)

사이트가 CDN, jquery.com 등 서드파티가 제공하는 스크립트, 이미지 등의 리소스에 의존하고 있다면 두 가지 선택사항이 있다.

이러한 리소스에도 프로토콜에 상대적인 URL을 사용해라. 서드파티가 HTTPS를 제공하지 않는다면 HTTPS를 제공해 달라고 요청해라. jquery.com을 포함해서 대부분의 서드파티는 HTTPS를 제공하고 있다.
당신이 제어하는 서버에서 리소스를 HTTP와 HTTPS로 모두 제공해라. 어찌 되더라도 이는 좋은 아이디어인데 사이트의 외형, 성능, 보안을 모두 제어할 수 있기 때문이다. 서드파티는 신뢰하지 않는 것이 좋다.

HTML 페이지뿐만이 아니라 스타일시트, 자바스크립트, 리다이렉 규칙 <link ...> 태그, CSP 선언에서도 사이트 내부 URL을 변경할 필요가 있다는 점을 명심해라.

HTTP를 HTTPS로 리다이렉트하기

요약

페이지 헤드에 캐노니컬 링크를 두어 사이트에 접근하는 가장 좋은 방법이 https임을 검색 엔진에 알릴 필요가 있다.

페이지에 <link rel="canonical" href="https://…"/>를 설정해라. 이는 사이트에 접근하는 좋은 방법을 검색엔진이 이해하는데 도움이 된다. 대부분의 웹서버는 단순한 리다이렉션 기능을 제공한다. HTTPS 버전이 캐노니컬이고 사용자는 HTTP에서 HTTPS로 리다이렉트 된다는 것을 검색엔진과 브라우저에 알려줄 때 301 (Moved Permanently)을 사용해라.

Strict Transport Security와 Secure Cookies를 켜라.

요약

301 리다이렉트의 비용을 피하려면 HTTP Strict Transport Security (HSTS) 를 사용해야 한다.
쿠키에 항상 Secure 플래그를 설정해라.

이번 장에서는

여기서는 HTTPS의 사용을 "강제"할 준비가 됐다. 우선 Strict Transport Security를 사용해서 클라이언트는 http://참조를 사용하더라도 항상 HTTPS로 서버에 접속한다는 것을 클라이언트에서 알려줘라. 이는 SSl Stripping같은 공격을 차단하고 "HTTP를 HTTPS로 리다이렉트하기"에서 설명한 301 리다이렉트의 라운드 트립 비용을 피할 수 있다.

NOTE: 당신의 사이트가 HSTS 호스트로 알고 있는 클라이언트는 TLS 설정에서 사이트가 오류를 발생하면 접근에 실패하게 된다. 이는 HSTS의 명시적인 설계 결정사항으로 네트워크 공격자가 클라이언트를 HTTPS 없이 사이트에 접근하도록 속일 수 없게 한다. HTTPS로 배포할 때 인증서 유효성 검사에 오류가 없도록 사이트 운영히 충분히 안정적이 되었을 때까지는 HSTS를 활성화 하지 마라.

Strict-Transport-Security 헤더를 설정해서 HTTP Strict Transport Security (HSTS)를 켜라. 다양한 서버에 대한 설명은 OWASP의 HSTS 페이지를 봐라.

대부분의 웹서버는 커스텀 헤더를 추가하는 기능을 제공한다.

NOTE: max-age는 수초로 설정해라. 이 값은 작은 값으로 시작해서 안정적으로 HTTPS 전용 사이트를 운영함에 따라 점진적으로 높힐 수 있다.

클라이언트가 HTTP로는 쿠키(인증이나 사이트 설정 같은)를 절대 보내지 않게 하는 것도 중요하다. 예를 들어 사용자의 인증 쿠키가 평문으로 노출된다면 다른 모든 것을 잘했더라도 전체 세션의 보안이 깨질 것이다.

그러므로 쿠키에 항상 Secure 플래그를 설정하도록 웹 애플리케이션을 설정해라. 다양한 애플리케이션 프레임워크에서 Secure 플래그를 설정하는 방법이 OWSAP에 나와 있다. 모든 애플리케이션 프레임워크를 플래그를 설정하는 방법이 있다.

마이그레이션 고려사항

이번 장에서는 운영자가 HTTPS로 바꿀 때 고려해야 하는 사항을 설명한다.

검색 순위

구글은 HTTPS를 사용하는 것을 좋은 검색 품질로 보여주고 있다. 검색 순위를 유지하면서 사이트를 전환하거나 이사하거나 마이그레이션하는 방법에 대한 가이드를 구글이 배포했다. Bing도 웹마스터 안내서를 발행했다.

성능

콘텐츠와 애플리케이션 계층의 최적화가 잘 되었을 때(Steve Souders의 책을 봐라.) 애플리케이션의 전체 비용에 비하면 남아있는 TLS 성능 문제는 보통은 아주 작다. 추가로 이러한 비용을 줄이거나 없앨 수 있다.(일반적인 TLS 최적화에 대한 좋은 충고는 Ilya Grigorik이 쓴 High Performance Browser Networking을 봐라.) Ivan Ristic의 OpenSSL Cookbook과 Bulletproof SSL And TLS도 참고해라.

일부의 경우 TLS가 성능을 높일 수 있는데 대부분은 HTTP/2를 활성화한 결과이다. Chris Palmer는 Chrome Dev Summit 2014에서 HTTPS and HTTP/2 performance에 대한 발표를 했다.

리퍼러 헤더

사용자가 당신의 HTTPS 사이트에서 다른 HTTP 사이트로 링크를 따라갈 때 유저 에이전트는 Referer 헤더를 보내지 않을 것이다. 이게 문제가 된다면 해결할 수 있는 몇 가지 방법이 있다.

다른 사이트도 HTTPS로 마이그레이션 해야 한다. 아마 이 가이드가 유용할 것이다. 리퍼리(referee) 사이트가 이 가이드의 "서버에 HTTPS 활성화하기"장을 따른다면 사이트에서 링크를 http://에서 https://로 바꿀 수 있거나 프로토콜 상대적인 링크를 사용할 수 있을 것이다.
레퍼러 헤더의 다양한 문제를 해결하는 새 리퍼러 정책 표준을 사용할 수 있다.

검색엔진이 HTTPS로 마이그레이션 하고 있으므로 HTTPS로 마이그레이션한다면 Referer 헤더를 지금보다 더 많이 볼 수 있을 것이다.

참조하는 페이지가 보안 프로토콜로 전송된다면 클라이언트는 (안전하지 않은) HTTP 요청에 Referer 헤더 필드를 포함하지 않아야 한다.(SHOULD NOT)
- HTTP RFC에서 발췌

광고 수익

사이트 운영자
광고로 사이트의 수익을 내는 사이트 운영자가 HTTPS로 마이그레이션하더라도 광고 효과가 줄어들 지는 않는다. 하지만 혼합된 컨텐트 보안 문제로 HTTP 아이프레임은 HTTPS 페이지에서 동작하지 않을 것이다. 여기서 복합적인 문제가 생긴다. 광고사가 HTTPS로 발행할 때까지 사이트 운영자는 광고 수익을 잃지 않으면서 HTTPS로 마이그레이션 할 수 없다. 하지만 사이트 운영자가 HTTPS로 마이그레이션 하기 전까지는 광고사는 HTTPS로 발행할 동기부여를 많이 갖지 못한다.

최소한 광고사는 HTTPS로 광고 서비스를 제공해야 한다.(이 가이드의 "서버에 HTTPS 활성화하기"를 따르는 것처럼) 많은 광고사가 이미 그렇게 하고 있다. HTTPS를 완전히 지원하지는 않더라도 시작은 해달라고 광고사에 요청해야 한다. 광고사가 적절하게 대응해 줄 때까지 이 가이드의 "사이트 내부 URL 상대적으로 만들기"를 완료하기를 미루고 싶을 것이다.

Outsider's Dev Story

HTTPS로 보안 강화하기