이 페이지에서는 다음 단계를 포함하여 서버에서 HTTPS를 설정하는 방법을 안내합니다.
- 2048비트 RSA 공개 키/비공개 키 쌍을 만듭니다.
- 공개 키가 삽입된 인증서 서명 요청 (CSR) 생성
- 인증 기관 (CA)과 CSR을 공유하여 최종 인증서 또는 인증서 체인을 수신합니다.
/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의 안내에 따라 최종 인증서 또는 인증서 체인을 받습니다.
CA마다 공개 키를 보증하는 서비스에 대해 다른 금액을 청구합니다.
여러 고유한 이름 (예: 모든 example.com, www.example.com, example.net, www.example.net) 또는 *.example.com와 같은 '와일드 카드' 이름을 포함하여 키를 두 개 이상의 DNS 이름에 매핑하는 옵션도 있습니다.
/etc/ssl (Linux 및 Unix)와 같이 웹에서 액세스할 수 없는 위치 또는 IIS (Windows)에서 인증서가 필요한 위치에 있는 모든 프런트엔드 서버에 인증서를 복사합니다.
서버에서 HTTPS 사용 설정
서버에서 HTTPS를 사용 설정하는 것은 웹페이지의 보안을 제공하는 데 중요한 단계입니다.
- Mozilla의 서버 구성 도구를 사용하여 HTTPS 지원을 위해 서버를 설정합니다.
- Qualys SSL 서버 테스트를 사용하여 사이트를 정기적으로 테스트하고 최소 A 또는 A+를 받으세요.
이 시점에서 중요한 운영 결정을 내려야 합니다. 다음 중 하나를 선택합니다.
- 웹 서버에서 콘텐츠를 제공하는 각 호스트 이름에 고유한 IP 주소를 할당합니다.
- 이름 기반 가상 호스팅을 사용합니다.
각 호스트 이름에 고유한 IP 주소를 사용했다면 모든 클라이언트에서 HTTP와 HTTPS를 모두 지원할 수 있습니다. 그러나 대부분의 사이트 운영자는 IP 주소를 절약하고 일반적으로 더 편리하기 때문에 이름 기반 가상 호스팅을 사용합니다.
서버에서 아직 HTTPS 서비스를 사용할 수 없는 경우 HTTP를 HTTPS로 리디렉션하지 말고 지금 사용 설정하세요. 자세한 내용은 HTTP를 HTTPS로 리디렉션을 참고하세요. 구매하여 설치한 인증서를 사용하도록 웹 서버를 구성합니다. Mozilla의 구성 생성기가 유용할 수 있습니다.
호스트 이름 또는 하위 도메인이 여러 개인 경우 각각 올바른 인증서를 사용해야 합니다.
이제 사이트가 운영되는 동안 Qualys SSL 서버 테스트를 사용하여 HTTPS 구성을 정기적으로 확인합니다. 사이트는 A 또는 A+를 받아야 합니다. 점수가 낮은 경우 모두 버그로 간주하고 주의 깊게 살펴보세요. 알고리즘과 프로토콜에 대한 새로운 공격이 항상 개발되고 있기 때문입니다.
인트라사이트 URL을 상대 경로로 만들기
이제 HTTP와 HTTPS에서 모두 사이트를 게재하므로 프로토콜과 관계없이 최대한 원활하게 작동해야 합니다. 중요한 요소는 인트라사이트 링크에 상대 URL을 사용하는 것입니다.
내부 사이트 URL과 외부 URL이 특정 프로토콜에 종속되지 않아야 합니다.
상대 경로를 사용하거나 //example.com/something.js와 같이 프로토콜을 생략합니다.
HTTPS를 사용하여 HTTP 리소스가 포함된 페이지를 제공하면 문제가 발생할 수 있습니다. 브라우저에서 안전하지 않은 리소스를 사용하는 안전한 페이지를 발견하면 사용자에게 페이지가 완전히 안전하지 않다고 경고하고 일부 브라우저에서는 HTTP 리소스를 로드하거나 실행하지 않아 페이지가 손상됩니다. 하지만 HTTP 페이지에 HTTPS 리소스를 안전하게 포함할 수 있습니다. 이러한 문제를 해결하는 방법에 관한 자세한 내용은 혼합 콘텐츠 수정을 참고하세요.
사이트의 다른 페이지로 연결되는 HTTP 기반 링크를 따라가면 사용자 환경이 HTTPS에서 HTTP로 다운그레이드될 수도 있습니다. 이 문제를 해결하려면 프로토콜 상대 (프로토콜이 없으며 //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>
<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>
<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>
실수를 방지하려면 수동이 아닌 스크립트로 링크를 업데이트하세요. 사이트의 콘텐츠가 데이터베이스에 있는 경우 데이터베이스의 개발 사본에서 스크립트를 테스트합니다. 사이트의 콘텐츠가 간단한 파일로만 구성된 경우 파일의 개발 사본에서 스크립트를 테스트합니다. 변경사항이 QA를 통과한 후에만 평소와 같이 프로덕션에 변경사항을 푸시합니다. Bram van Damme의 스크립트 또는 유사한 도구를 사용하여 사이트에서 혼합 콘텐츠를 감지할 수 있습니다.
다른 사이트의 리소스를 포함하는 것이 아니라 다른 사이트에 연결하는 경우 프로토콜을 변경하지 마세요. 이러한 사이트의 운영 방식은 관리할 수 없습니다.
대규모 사이트의 이전을 원활하게 하려면 프로토콜 상대 URL을 사용하는 것이 좋습니다. 아직 HTTPS를 완전히 배포할 수 있는지 확실하지 않은 경우 사이트에서 모든 하위 리소스에 HTTPS를 강제로 사용하면 역효과가 날 수 있습니다. HTTPS가 새롭고 이상하게 느껴지는 기간이 있을 수 있으며 HTTP 사이트는 여전히 잘 작동해야 합니다. 시간이 지남에 따라 이전을 완료하고 HTTPS를 고정합니다(다음 두 섹션 참고).
사이트가 CDN 또는 jquery.com과 같은 서드 파티에서 제공하는 스크립트, 이미지 또는 기타 리소스에 종속되는 경우 다음 두 가지 옵션이 있습니다.
- 이러한 리소스에는 프로토콜 상대 URL을 사용합니다. 서드 파티에서 HTTPS를 제공하지 않는 경우 요청하세요. jquery.com을 비롯한 대부분의 사이트는 이미 이를 준수하고 있습니다.
- HTTP와 HTTPS를 모두 제공하는 관리하는 서버에서 리소스를 제공합니다. 어쨌든 이렇게 하는 것이 좋습니다. 이렇게 하면 사이트의 모양, 성능, 보안을 더 효과적으로 관리할 수 있고 서드 파티를 신뢰하여 사이트 보안을 유지하지 않아도 되기 때문입니다.
HTTP를 HTTPS로 리디렉션
검색엔진에 HTTPS를 사용하여 사이트에 액세스하도록 지시하려면 <link rel="canonical" href="https://…"/> 태그를 사용하여 각 페이지의 상단에 표준 링크를 배치합니다.
엄격한 전송 보안 및 보안 쿠키 사용 설정
이제 HTTPS 사용을 '고정'할 준비가 되었습니다.
- HTTP Strict Transport Security (HSTS)를 사용하여 301 리디렉션의 비용을 방지합니다.
- 쿠키에 항상 Secure 플래그를 설정합니다.
먼저 Strict Transport Security를 사용하여 클라이언트에게 http:// 참조를 따를 때도 항상 HTTPS를 사용하여 서버에 연결해야 한다고 알립니다. 이렇게 하면 SSL 제거와 같은 공격을 방지하고 HTTP를 HTTPS로 리디렉션에서 사용 설정한 301 redirect의 왕복 비용을 방지할 수 있습니다.
HSTS를 사용 설정하려면 Strict-Transport-Security 헤더를 설정합니다. OWASP의 HSTS 페이지에는 다양한 종류의 서버 소프트웨어에 대한 안내 링크가 있습니다.
대부분의 웹 서버는 맞춤 헤더를 추가하는 유사한 기능을 제공합니다.
또한 클라이언트가 HTTP를 통해 쿠키 (예: 인증 또는 사이트 환경설정)를 전송하지 않도록 하는 것도 중요합니다. 예를 들어 사용자의 인증 쿠키가 일반 텍스트로 노출되면 다른 모든 작업을 올바르게 수행했더라도 전체 세션에 대한 보안 보장이 사라집니다.
이를 방지하려면 웹 앱을 변경하여 설정하는 쿠키에 항상 Secure 플래그를 설정하도록 합니다. 이 OWASP 페이지에서는 여러 앱 프레임워크에서 Secure 플래그를 설정하는 방법을 설명합니다. 모든 애플리케이션 프레임워크에는 플래그를 설정하는 방법이 있습니다.
대부분의 웹 서버는 간단한 리디렉션 기능을 제공합니다. 301 (Moved Permanently)를 사용하여 검색엔진과 브라우저에 HTTPS 버전이 표준 버전임을 나타내고 사용자를 HTTP에서 사이트의 HTTPS 버전으로 리디렉션합니다.
검색 순위
Google은 HTTPS를 긍정적인 검색 품질 지표로 사용합니다. Google에서는 검색 순위를 유지하면서 사이트를 이전, 이동 또는 이전하는 방법에 관한 가이드를 게시하고 있습니다. Bing에서는 웹마스터 가이드라인도 게시합니다.
성능
콘텐츠 및 애플리케이션 레이어가 잘 조정된 경우 (조언은 Steve Souders의 책 참고) 남은 TLS 성능 문제는 일반적으로 애플리케이션의 전체 비용에 비해 작습니다. 이러한 비용을 줄이고 상각할 수도 있습니다. TLS 최적화에 관한 도움말은 Ilya Grigorik의 고성능 브라우저 네트워킹, Ivan Ristic의 OpenSSL Cookbook 및 Bulletproof SSL And TLS를 참고하세요.
경우에 따라 TLS를 사용하면 HTTP/2를 사용할 수 있게 되어 성능이 향상될 수 있습니다. 자세한 내용은 Chrome Dev Summit 2014에서 HTTPS 및 HTTP/2 성능에 관한 크리스 팔머의 강연을 참고하세요.
리퍼러 헤더
사용자가 HTTPS 사이트에서 다른 HTTP 사이트로 연결되는 링크를 클릭하면 사용자 에이전트는 Referrer 헤더를 전송하지 않습니다. 이 문제가 발생하는 경우 해결 방법은 다음과 같습니다.
- 다른 사이트는 HTTPS로 이전해야 합니다. 추천 사이트에서 이 가이드의 서버에서 HTTPS 사용 설정 섹션을 완료한 경우 사이트의 링크를
http://에서https://로 변경하거나 프로토콜 상대 링크를 사용할 수 있습니다. - 리퍼러 헤더와 관련된 다양한 문제를 해결하려면 새로운 리퍼러 정책 표준을 사용하세요.
광고 수익
광고를 게재하여 사이트에서 수익을 창출하는 사이트 운영자는 HTTPS로 이전해도 광고 노출수가 줄지 않도록 해야 합니다. 그러나 혼합된 콘텐츠 보안 문제로 인해 HTTP <iframe>는 HTTPS 페이지에서 작동하지 않습니다.
광고주가 HTTPS를 통해 게시할 때까지 사이트 운영자는 광고 수익을 잃지 않고는 HTTPS로 이전할 수 없습니다. 하지만 사이트 운영자가 HTTPS로 이전할 때까지 광고주는 HTTPS를 게시할 동기가 거의 없습니다.
HTTPS를 통해 광고 서비스를 제공하는 광고주를 사용하고 HTTPS를 전혀 게재하지 않는 광고주에게 적어도 HTTPS를 옵션으로 제공하도록 요청하여 이 교착 상태를 타파할 수 있습니다. 충분한 수의 광고주가 제대로 상호 운용할 때까지 Make IntraSite URLs relative를 완료하는 작업을 연기해야 할 수 있습니다.