서버에서 HTTPS 사용 설정

크리스 팔머
크리스 팔머

이 도움말에서 다루는 단계

  1. 2048비트 RSA 공개 키/비공개 키 쌍을 만듭니다.
  2. 공개 키를 포함하는 CSR (인증서 서명 요청)을 생성합니다.
  3. CSR을 인증 기관 (CA)과 공유하여 최종 인증서 또는 인증서 체인을 받습니다.
  4. /etc/ssl 등 웹에서 액세스할 수 없는 위치 (Linux 및 Unix) 또는 IIS에서 인증서를 필요로 하는 곳 (Windows)에 최종 인증서를 설치합니다.

키 및 인증서 서명 요청 생성

이 섹션에서는 대부분의 Linux, BSD 및 Mac OS X 시스템과 함께 제공되는 openssl 명령줄 프로그램을 사용하여 비공개/공개 키 및 CSR를 생성합니다.

공개 키/비공개 키 쌍 생성

먼저 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)에 삽입합니다. 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 (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, 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)마다 CSR을 전송하는 데 필요한 방법이 다릅니다. 웹사이트에 있는 양식을 사용하거나 이메일로 CSR을 보내는 등 방법이 있습니다. 일부 CA (또는 리셀러)는 프로세스의 일부 또는 전체 (경우에 따라 키 쌍 및 CSR 생성 포함)를 자동화할 수도 있습니다.

CSR을 CA에 전송하고 안내에 따라 최종 인증서 또는 인증서 체인을 수신합니다.

공개 키 보증 서비스 수수료는 CA마다 다를 수 있습니다.

여러 고유한 이름 (예: example.com, www.example.com, example.net, www.example.net 모두) 또는 *.example.com과 같은 '와일드 카드' 이름을 포함하여 키를 2개 이상의 DNS 이름에 매핑하는 옵션도 있습니다.

예를 들어 한 CA가 현재 다음과 같은 가격을 제공하고 있습니다.

  • 표준: $16/년, example.com 및 www.example.com에 유효.
  • 와일드 카드: $150/년, example.com 및 *.example.com에 유효.

이 가격을 기준으로 하면 하위 도메인이 9개 이상인 경우 와일드 카드 인증서가 효율적입니다. 그렇지 않으면 단일 이름 인증서를 하나 이상 구입하는 것이 좋습니다. 하위 도메인이 5개 이상인 경우에는 서버에 HTTPS를 사용 설정할 때 와일드 카드 인증서가 더 편리할 수 있습니다.

/etc/ssl와 같이 웹에서 액세스할 수 없는 곳 (Linux 및 Unix) 또는 IIS에서 인증서를 필요로 하는 곳 (Windows)의 모든 프런트엔드 서버에 인증서를 복사합니다.

서버에서 HTTPS 사용 설정

서버에서 HTTPS를 사용 설정하는 것은 웹페이지에 보안을 제공하는 중요한 단계입니다.

  • Mozilla의 Server Configuration 도구를 사용하여 HTTPS를 지원하도록 서버를 설정합니다.
  • Qualys의 편리한 SSL 서버 테스트로 사이트를 정기적으로 테스트하여 A 또는 A+ 이상의 등급을 획득합니다.

이 시점에서 중요한 작업 결정을 내려야 합니다. 다음 중 하나를 선택합니다.

  • 웹 서버에서 콘텐츠를 제공하는 호스트 이름 각각에 고유한 IP 주소를 지정합니다.
  • 이름 기반 가상 호스팅을 사용합니다.

각 호스트 이름에 고유한 IP 주소를 사용한 경우 모든 클라이언트에 HTTP와 HTTPS를 모두 쉽게 지원할 수 있습니다.

하지만 이름 기반 가상 호스팅이 일반적으로 더 편리하므로 대부분의 사이트 운영자는 IP 주소를 보존하기 위해 사용합니다. Windows XP 및 Android 2.3 이전 버전의 IE에서 발생하는 문제는 HTTPS 이름 기반 가상 호스팅에 중요한 SNI(서버 이름 표시)를 이해하지 못한다는 것입니다.

SNI를 지원하지 않는 클라이언트는 최신 소프트웨어로 대체될 것이며, 곧 그렇게 되기를 바랍니다. 요청 로그의 사용자 에이전트 문자열을 모니터링하여 충분한 수의 사용자 모집단이 최신 소프트웨어로 이전한 시점을 파악합니다. (임곗값을 5% 미만이거나 1% 미만으로 설정할 수 있습니다.)

서버에서 HTTPS 서비스를 사용할 수 없는 경우 지금 사용 설정합니다(HTTP를 HTTPS로 리디렉션하지 않음. 아래 참조). 구입하고 설치한 인증서를 사용하도록 웹 서버를 구성합니다. 이 경우 Mozilla의 편리한 구성 생성기가 유용할 수 있습니다.

호스트 이름 또는 하위 도메인이 많은 경우 각각 올바른 인증서를 사용해야 합니다.

지금은 물론 사이트 전체 기간 동안 Qualys의 편리한 SSL 서버 테스트를 통해 HTTPS 구성을 확인하세요. 사이트가 A 또는 A+ 등급을 받아야 하며 이보다 낮은 등급을 초래하는 모든 원인은 버그로 처리해야 합니다. (알고리즘과 프로토콜에 대한 공격이 항상 개선되고 있기 때문에 현재 A 등급은 향후 B 등급입니다.)

사이트 내 URL을 상대 URL로 설정

이제 HTTP와 HTTPS로 사이트를 제공하므로 프로토콜에 관계없이 작업이 최대한 원활하게 작동해야 합니다. 중요한 요소는 사이트 내 링크에 상대 URL을 사용하는 것입니다.

사이트 내 URL과 외부 URL이 프로토콜에 구속되지 않아야 합니다. 즉, 상대 경로를 사용하거나 //example.com/something.js과 같은 프로토콜을 제외해야 합니다.

HTTPS를 통해 혼합 콘텐츠라고 하는 HTTP 리소스가 포함된 페이지를 제공하면 문제가 발생합니다. 브라우저는 사용자에게 HTTPS의 모든 강점이 사라졌다고 경고합니다. 실제로 활성 혼합 콘텐츠 (스크립트, 플러그인, CSS, iframe)의 경우 브라우저가 콘텐츠를 로드하거나 실행하지 않아 페이지가 깨지는 경우가 많습니다. HTTP 페이지에 HTTPS 리소스를 포함해도 괜찮습니다.

또한 사이트의 다른 페이지에 연결하면 사용자가 HTTPS에서 HTTP로 다운그레이드될 수 있습니다.

이러한 문제는 페이지에 http:// 스키마를 사용하는 정규화된 사이트 내 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>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
정규화된 사이트 내 URL을 사용하지 않습니다.

즉, 사이트 내 URL을 가능한 한 상대적인 상대 URL로 만들어야 합니다. 즉, 프로토콜 기준 (프로토콜 없음, //example.com로 시작) 또는 호스트 기준 (/jquery.js과 같이 경로만으로 시작)을 만들어야 합니다.

의견을 제시하지
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
상대적인 사이트 내 URL을 사용합니다.
의견을 제시하지
<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>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
또는 프로토콜 기준 사이트 내 URL을 사용합니다.
의견을 제시하지
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
가능한 경우 사이트 간 URL에 HTTPS URL을 사용합니다.

이 작업은 직접 하지 말고 스크립트를 사용하여 수행하세요. 사이트 콘텐츠가 데이터베이스에 있는 경우 데이터베이스의 개발 복사본에서 스크립트를 테스트하세요. 사이트 콘텐츠가 간단한 파일로 구성된 경우 파일의 개발 복사본에서 스크립트를 테스트하세요. 변경사항이 QA를 통과한 후에만 평소와 같이 프로덕션에 푸시합니다. 브람 반 담의 스크립트 또는 이와 유사한 스크립트를 사용하여 사이트의 혼합 콘텐츠를 감지할 수 있습니다.

다른 사이트의 리소스를 포함하는 것과 달리 다른 사이트에 연결할 때는 해당 사이트의 작동 방식을 제어할 수 없으므로 프로토콜을 변경하지 마세요.

대규모 사이트의 마이그레이션을 더 원활하게 하려면 프로토콜 기준 URL을 사용하는 것이 좋습니다. 아직 HTTPS를 완전히 배포할 수 있는지 확실하지 않은 경우 사이트에서 모든 하위 리소스에 HTTPS를 사용하도록 강제하면 역효과가 날 수 있습니다. 일정 기간 HTTPS가 새롭고 이상할 가능성이 크며 HTTP 사이트도 여전히 작동해야 합니다. 시간이 지남에 따라 마이그레이션을 완료하고 HTTPS를 잠급니다 (다음 두 섹션 참조).

사이트가 타사(예: CDN 또는 jquery.com)에서 제공하는 스크립트, 이미지 또는 기타 리소스를 사용하는 경우 다음 두 가지 옵션을 사용할 수 있습니다.

  • 이러한 리소스에 대해 프로토콜 기준 URL을 사용합니다. 서드 파티에서 HTTPS를 지원하지 않으면 HTTPS를 지원하도록 요청합니다. jquery.com을 포함하여 대부분의 업체에서 이미 지원되고 있습니다.
  • 사용자가 제어하고 HTTP와 HTTPS를 모두 제공하는 서버에서 리소스를 제공합니다. 사이트의 모양, 성능 및 보안을 더 효과적으로 제어할 수 있으므로 이 방법을 사용하는 것이 좋습니다. 또한 서드 파티를 신뢰할 필요가 없으므로 언제나 좋습니다.

HTTP를 HTTPS로 리디렉션

HTTPS가 사이트에 도달하는 가장 좋은 방법임을 검색엔진에 알리려면 표준 링크를 페이지 헤드에 추가해야 합니다.

페이지에 <link rel="canonical" href="https://…"/> 태그를 설정합니다. 이렇게 하면 검색엔진이 사이트에 액세스할 수 있는 가장 좋은 방법을 결정하는 데 도움이 됩니다.

Strict Transport Security 및 보안 쿠키 사용 설정

이제 HTTPS 사용을 '락인(lock in)'할 준비가 되었습니다.

  • 301 리디렉션 비용을 방지하려면 HSTS (HTTP Strict Transport Security)를 사용하세요.
  • 항상 쿠키에 보안 플래그를 설정하세요.

먼저 Strict Transport Security를 사용하여 http:// 참조를 따르는 경우에도 항상 HTTPS를 통해 서버에 연결해야 함을 클라이언트에 알립니다. 이렇게 하면 SSL 스트리핑과 같은 공격이 방지되고 HTTP를 HTTPS로 리디렉션에서 사용 설정한 301 redirect의 왕복 비용도 방지됩니다.

Strict-Transport-Security 헤더를 설정하여 HSTS (HTTP Strict Transport Security)를 사용 설정합니다. OWASP의 HSTS 페이지에 다양한 서버 소프트웨어에 대한 안내 링크가 있습니다.

대부분의 웹 서버는 맞춤 헤더를 추가하는 유사한 기능을 제공합니다.

또한 클라이언트가 HTTP를 통해 쿠키 (예: 인증 또는 사이트 환경설정용)를 전송하지 않도록 하는 것도 중요합니다. 예를 들어 사용자의 인증 쿠키가 일반 텍스트로 노출되면 다른 모든 작업을 올바르게 완료했더라도 전체 세션의 보안이 보장되지 않게 됩니다.

따라서 웹 애플리케이션이 설정하는 쿠키에 항상 보안 플래그를 설정하도록 웹 애플리케이션을 변경하세요. 이 OWASP 페이지에서는 여러 애플리케이션 프레임워크에서 보안 플래그를 설정하는 방법을 설명합니다. 모든 애플리케이션 프레임워크에는 플래그를 설정하는 방법이 있습니다.

대부분의 웹 서버는 간단한 리디렉션 기능을 제공합니다. 301 (Moved Permanently)를 사용하여 검색엔진과 브라우저에 HTTPS 버전이 표준임을 알리고 사용자를 HTTP에서 HTTPS 버전의 사이트로 리디렉션하세요.

검색 순위

Google에서는 HTTPS를 긍정적인 검색 품질 지표로 사용합니다. Google에서는 검색 순위를 유지하면서 사이트를 전송, 이동 또는 이전하는 방법에 관한 가이드도 게시합니다. Bing도 웹마스터를 위한 가이드라인을 게시합니다.

성능

콘텐츠와 애플리케이션 레이어가 잘 조정되면 (유용한 조언이 필요하면 Steve Souders의 책 참고) 나머지 TLS 성능 문제는 일반적으로 애플리케이션의 전체 비용에 비해 작습니다. 또한 이러한 비용은 절감하고 상환할 수 있습니다 TLS 최적화 및 일반적으로 Ilya Grigorik의 고성능 브라우저 네트워킹을 참조하세요. Ivan Ristic의 OpenSSL 설명서Bulletproof SSL 및 TLS도 참조하세요.

경우에 따라 TLS는 주로 HTTP/2를 가능하게 하여 성능을 향상할 수 있습니다. 크리스 팔머가 Chrome Dev Summit 2014에서 HTTPS 및 HTTP/2 성능에 관한 강연을 했습니다.

리퍼러 헤더

사용자가 HTTPS 사이트의 링크를 따라 다른 HTTP 사이트로 이동할 때 사용자 에이전트는 리퍼러 헤더를 전송하지 않습니다. 문제가 있는 경우 다음과 같은 여러 가지 방법으로 해결할 수 있습니다.

  • 다른 사이트를 HTTPS로 이전해야 합니다. 추천 대상 사이트에서 이 가이드의 서버에 HTTPS 사용 설정 섹션을 완료할 수 있는 경우 사이트의 링크를 http://에서 https://로 변경하거나 프로토콜 기준 링크를 사용할 수 있습니다.
  • 리퍼러 헤더와 관련된 다양한 문제를 해결하려면 새 리퍼러 정책 표준을 사용하세요.

검색엔진이 HTTPS로 이전되므로 향후 HTTPS로 이전할 때 리퍼러 헤더가 더 많이 표시될 수 있습니다.

광고 수익

광고를 표시하여 사이트에서 수익을 창출하는 사이트 운영자는 HTTPS로 이전해도 광고 노출수가 줄어들지 않기를 바랍니다. 하지만 혼합 콘텐츠 보안 문제로 인해 HTTP <iframe>는 HTTPS 페이지에서 작동하지 않습니다. 여기에는 복잡한 집단 행동 문제가 있습니다. 광고주가 HTTPS를 통해 게시할 때까지 사이트 운영자는 광고 수익 손실 없이 HTTPS로 이전할 수 없습니다. 하지만 사이트 운영자가 HTTPS로 이전할 때까지 광고주는 HTTPS를 게시할 동기가 거의 없습니다.

광고주는 적어도 HTTPS를 통해 광고 서비스를 제공해야 합니다 (예: 이 페이지의 '서버에서 HTTPS 사용 설정' 섹션 작성). 많은 광고주가 이미 HTTPS를 사용하고 있습니다. 적어도 HTTPS를 전혀 제공하지 않는 광고주에게는 이를 시작하도록 요청해야 합니다. 다수의 광고주가 제대로 상호 운용할 때까지 사이트 내 URL을 상대 URL로 만들기 완료를 연기하는 것이 좋습니다.