서버에서 HTTPS 사용 설정

Chris Palmer
Chris Palmer

이 페이지에서는 다음 단계를 포함하여 서버에 HTTPS를 설정하는 방법을 안내합니다.

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

키 및 인증서 서명 요청 생성

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

공개 키/비공개 키 쌍 생성

시작하려면 2,048비트 RSA 키 쌍을 생성합니다. 짧은 키는 무차별 대입 추측 공격으로 손상될 수 있으며 키가 길면 불필요한 리소스를 사용합니다.

다음 명령어를 사용하여 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 이름에 매핑하는 옵션도 있습니다.

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

서버에서 HTTPS 사용 설정

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

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

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

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

각 호스트 이름에 고유한 IP 주소를 사용한 경우 모든 클라이언트에 HTTP와 HTTPS를 모두 지원할 수 있습니다. 하지만 이름 기반 가상 호스팅이 일반적으로 더 편리하므로 대부분의 사이트 운영자는 IP 주소를 보존하기 위해 사용합니다.

서버에서 HTTPS 서비스를 사용할 수 없는 경우 지금 사용 설정합니다(HTTP를 HTTPS로 리디렉션하지 않음). 자세한 내용은 HTTP를 HTTPS로 리디렉션을 참조하세요. 구매하여 설치한 인증서를 사용하도록 웹 서버를 구성합니다. Mozilla의 구성 생성기가 유용할 수 있습니다.

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

지금, 그리고 사이트 전체 기간 동안 정기적으로 Qualys SSL 서버 테스트를 사용하여 HTTPS 구성을 확인합니다. 사이트는 A 또는 A+ 등급을 받아야 합니다. 이보다 낮은 등급을 초래하는 모든 원인은 버그로 간주하고, 알고리즘과 프로토콜을 대상으로 하는 새로운 공격이 항상 개발되고 있기 때문에 부지런히 주의를 기울여야 합니다.

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

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

사이트 내 URL 및 외부 URL이 특정 프로토콜에 종속되지 않아야 합니다. 상대 경로를 사용하거나 //example.com/something.js에서와 같이 프로토콜을 생략합니다.

HTTPS를 사용하여 HTTP 리소스가 포함된 페이지를 제공하면 문제가 발생할 수 있습니다. 브라우저에서 안전하지 않은 리소스를 사용하는 다른 보안 페이지를 발견하면 사용자에게 이 페이지가 완전히 안전하지 않다고 경고하며, 일부 브라우저는 HTTP 리소스의 로드 또는 실행을 거부하여 페이지가 손상됩니다. 하지만 HTTP 페이지에 HTTPS 리소스를 안전하게 포함할 수 있습니다. 이러한 문제를 해결하는 방법에 관한 자세한 내용은 혼합 콘텐츠 수정을 참고하세요.

사이트의 다른 페이지로 연결되는 HTTP 기반 링크를 따라가면 사용자 환경이 HTTPS에서 HTTP로 다운그레이드될 수 있습니다. 이 문제를 해결하려면 사이트 내 URL을 프로토콜 기준 (프로토콜 없음, //example.com로 시작) 또는 호스트 기준 (/jquery.js와 같이 경로만으로 시작)으로 만들어 가능한 한 상대 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>
상대적인 사이트 내 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>
가능한 경우 다른 사이트로 연결되는 링크에 HTTPS URL을 사용합니다.

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

다른 사이트의 리소스를 포함하는 것과 달리 다른 사이트에 연결할 때는 프로토콜을 변경하지 마세요. 이러한 사이트의 작동 방식은 광고주가 제어할 수 없습니다.

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

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

  • 이러한 리소스에 대해 프로토콜 기준 URL을 사용합니다. 타사에서 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의 왕복 비용이 방지됩니다.

HSTS를 사용 설정하려면 Strict-Transport-Security 헤더를 설정하세요. OWASP의 HSTS 페이지에 다양한 종류의 서버 소프트웨어에 대한 안내 링크가 있습니다.

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

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

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

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

검색 순위

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

성능

콘텐츠와 애플리케이션 레이어가 잘 조정되면 (자세한 내용은 Steve Souders의 책 참고) 나머지 TLS 성능 문제는 일반적으로 애플리케이션의 전체 비용에 비해 작습니다. 또한 이러한 비용은 절감하고 분할 상환할 수 있습니다. TLS 최적화에 대한 도움말은 Ilya Grigorik의 High Performance Browser Networking, Ivan Ristic의 OpenSSL 설명서Bulletproof SSL 및 TLS를 참조하세요.

경우에 따라 TLS는 주로 HTTP/2를 가능하게 하여 성능을 개선할 수 있습니다. 자세한 내용은 Chrome Dev Summit 2014에서 HTTPS 및 HTTP/2 성능에 관한 크리스 팔머의 강연을 참고하세요.

리퍼러 헤더

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

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

광고 수익

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

HTTPS를 통해 광고 서비스를 제공하는 광고주를 통해 HTTPS를 전혀 제공하지 않는 광고주에게 적어도 이를 선택하도록 요청하여 이 교착 상태를 해제하는 프로세스를 시작할 수 있습니다. 많은 광고주가 제대로 상호 운용할 때까지 사이트 내 URL을 상대 URL로 만들기 완료를 연기해야 할 수도 있습니다.