WordPress HTTPS, SSL 및 TLS – 웹사이트 관리자를 위한 가이드

게시 됨: 2021-02-01

웹 사이트를 방문하면 브라우저( 클라이언트 라고도 함)가 웹 서버에 HTTP 요청 을 보냅니다. 웹 서버가 HTTP 응답 을 보내면 브라우저는 페이지를 화면에 렌더링할 수 있습니다. 그러나 HTTP 트래픽에는 문제가 있습니다. 일반 텍스트 프로토콜입니다. 이로 인해 스누핑 및 간섭에 취약합니다.

공격자가 귀하와 동일한 네트워크에 있는 경우 HTTP 트래픽을 가로채서 읽을 수 있습니다. 그들은 또한 서버에 대한 귀하의 요청과 귀하에 대한 서버의 응답을 모두 수정할 수 있습니다. 이를 MitM(Man-in-Middle) 공격이라고 합니다. 이것은 호텔 로비 및 공공 장소와 같은 공용 WiFi에서 쉽게 발생할 수 있습니다.

이것이 웹사이트가 HTTPS에 있어야 하는 이유입니다. 따라서 트래픽을 가로챌 수 없습니다. 이 문서에서는 HTTPS, SSL 및 TLS가 무엇인지 설명합니다. 또한 HTTPS에서 작동하도록 WordPress 웹 사이트를 구성하는 방법도 설명합니다.

목차

  • SSL 및 TLS란 무엇입니까?
  • HTTPS란 무엇입니까?
    • HTTPS는 어떻게 작동합니까?
      • TLS 핸드셰이크
      • 공개 및 개인 키(키 쌍)
  • 내 WordPress 웹 사이트에 HTTPS가 정말로 필요합니까?
    • HTTPS TLS 인증서(일명 SSL 인증서) 받기
    • 공유 및 관리 WordPress 호스팅의 HTTPS
  • WordPress HTTPS 구성
    • 웹 서버 구성
    • WordPress URL을 HTTPS로 구성
    • WordPress 대시보드에서 TLS 시행(보너스 팁)
  • HSTS(HTTP Strict Transport Security) 추가
    • 웹 서버에서 HSTS 구성
    • TLS 암호
    • 내 WordPress는 HTTPS에서 실행됩니다. 안전한가요?

SSL 및 TLS란 무엇입니까?

인터넷이 성장하기 시작하면서 아무도 트래픽을 도청하거나 수정할 수 없도록 클라이언트와 서버 간에 안전하게 정보를 전송하는 메커니즘이 필요하다는 것이 분명해졌습니다. SSL 또는 SSL(Secure Socket Layer)을 입력하십시오. SSL은 이 문제를 해결하기 위해 1995년 Netscape에서 처음 개발한 인터넷 보안 프로토콜입니다.

보다 구체적으로 SSL은 다음을 수행하도록 설정되었습니다.

  • 암호화 — 무단 제3자가 도청을 통해 가로챌 수 없도록 트래픽을 암호화합니다.
  • 인증 — 클라이언트가 말하는 서버가 실제로 그들이 말하는 서버인지 확인하기 위해,
  • 무결성 — 클라이언트와 서버 간에 전송된 데이터가 도중에 다른 사람에 의해 수정되지 않도록 합니다.

그러나 시간이 지남에 따라 보안 연구원은 SSL에서 많은 보안 문제를 식별했습니다. 따라서 SSL은 TLS(전송 계층 보안 프로토콜)로 대체되었습니다. SSL과 TLS의 내부적 차이는 극심하지만 TLS의 목적은 대체로 동일합니다.

참고: SSL이 TLS를 참조하는 데 사용되는 것을 자주 볼 수 있습니다. SSL은 레거시 프로토콜이며 더 이상 사용하기에 안전하지 않습니다. 그러나 인기로 인해 많은 사람들이 여전히 SSL을 약어로 사용하지만 TLS를 의미 합니다.

HTTPS란 무엇입니까?

HTTPS 또는 Hypertext Transfer Protocol Secure는 HTTP 프로토콜의 보안 버전입니다. HTTPS는 이전에 사용된 SSL(Secure Socket Layer)보다 개선되고 더 안전한 프로토콜인 TLS(전송 계층 보안)에 의존합니다. TLS는 HTTPS 요청 및 응답에 암호화, 인증 및 무결성을 제공합니다.

HTTPS는 TLS 터널 을 통과하는 HTTP(프로토콜의 일반 텍스트 버전) 요청 및 응답으로 생각할 수 있습니다. 이에 대한 기술 용어는 캡슐화 입니다. TLS는 HTTP뿐만 아니라 다른 프로토콜을 캡슐화하는 데 사용될 수 있습니다.

브라우저 탐색 표시줄에서 URL 시작 부분(HTTPS로 시작)을 보거나 녹색 자물쇠로 HTTPS를 사용하는 웹사이트를 찾을 수 있습니다. HTTP에서 웹사이트를 탐색하는 경우 브라우저는 해당 웹사이트를 안전하지 않음 으로 표시합니다.

안전하지 않은 것으로 표시된 HTTP 웹사이트

HTTPS는 어떻게 작동합니까?

HTTPS를 사용하여 웹 페이지를 요청하면 브라우저와 웹 서버가 TLS 핸드셰이크 라는 프로세스를 시작합니다. TLS 핸드셰이크는 클라이언트와 서버가 통신 여부와 방법을 결정하는 방법입니다. TLS 핸드셰이크 과정에서 클라이언트와 서버는 다음을 수행합니다.

  • 사용할 TLS 프로토콜 버전 결정(TLS 1.0, 1.2, 1.3…),
  • 사용할 암호 모음(보안 통신을 설정하는 데 사용되는 암호화 알고리즘 집합)에 동의합니다.
  • 서버의 신원을 인증하고,
  • 안전한 통신을 위해 핸드셰이크가 완료된 후 사용할 암호화 키를 생성합니다.

TLS 핸드셰이크

TLS 핸드셰이크 중에 서버는 클라이언트가 서버를 인증할 수 있는지 확인하기 위해 클라이언트에 인증서를 보냅니다. 인증서는 여권과 유사합니다. 인증서는 브라우저에 증명될 수 있는 웹사이트의 ID를 독립적으로 설정하는 인증 기관(CA)이라는 신뢰할 수 있는 중앙 기관에서 발급합니다.

공개 및 개인 키(키 쌍)

웹 서버가 클라이언트에 보내는 TLS 인증서(종종 SSL 인증서라고도 함)에는 공개 키 가 포함되어 있습니다. 공개 키 는 keypair 라는 두 개의 특수 키 중 하나입니다. 키 쌍 은 두 개의 키로 구성됩니다. 공개 키 와 개인 키 . 공개 키 는 클라이언트와 공유되지만 개인 키 는 서버에서 비밀로 유지되며 절대 공개되지 않습니다. 키 쌍 은 함께 위조됩니다.

공개 키와 개인 키 쌍은 특히 흥미로운 관계를 가지고 있습니다. 서버의 개인 키(이것은 비밀이고 서버만 알아야 함)를 모른 채 클라이언트는 서버의 공개 키를 사용하여 데이터를 암호화 할 수 있으며 서버는 개인 키를 사용하여 해독 할 수 있습니다. .

이것이 혼란스럽게 들린다면 "서버"가 자물쇠로 보호된 열린 여행 가방(공개 키)을 "브라우저"로 보낸 것처럼 생각하십시오. 여행 가방에 무언가를 넣고 자물쇠를 잠그면 "서버"만 자물쇠의 열쇠(개인 열쇠)는 안에 무엇이 있는지 볼 수 있습니다.

내 WordPress 웹 사이트에 HTTPS가 정말로 필요합니까?

예. 웹사이트에서 제공하는 트래픽의 종류(개인 식별 정보(PII), 카드 소지자 데이터 또는 고양이 사진)에 관계없이 HTTPS를 통해 웹사이트를 제공하지 말아야 할 이유는 전혀 없습니다 .

우선, HTTP에서 웹사이트를 실행할 때 해커는 쉽게 WordPress 비밀번호와 자격 증명을 훔쳐 웹사이트를 해킹할 수 있습니다. 그들은 무료로 사용 가능한 도구를 사용하여 이 모든 작업을 수행할 수 있습니다.

보안 이점과 더 나은 사용자 경험 외에도 여러 성능 이점을 제공하는 새로운 HTTP/2 프로토콜은 웹 브라우저 내에서 TLS 없이는 사용할 수 없습니다. 또한 HTTPS는 SEO(검색 엔진 최적화)의 이점도 가지고 있으며 Google 검색 순위 알고리즘의 일부입니다.

HTTPS TLS 인증서(일명 SSL 인증서) 받기

HTTPS를 설정하려면 모든 것을 직접 설정하는 경우 TLS 인증서가 필요합니다. 수십 가지의 유료 TLS 인증서를 볼 수 있지만 Let's Encrypt라는 비영리 인증 기관에서 무료 TLS 인증서를 얻을 수 있습니다. Let's Encrypt에서 무료로 받는 인증서와 유료로 제공하는 인증서 간에는 전혀 다른 점이 없습니다.

공유 및 관리 WordPress 호스팅의 HTTPS

관리 또는 공유 호스팅 솔루션의 경우 호스팅 제공업체가 HTTPS 추가에 대해 비용을 청구하거나 청구하지 않을 수 있습니다. 이 경우 인증서 비용을 지출하기 전에 고객 지원에 Let's Encrypt 인증서를 사용할 수 있는지 문의하십시오. 대신 서비스. Let's Encrypt 커뮤니티 포럼도 도움이 될 수 있는 훌륭한 리소스입니다.

WordPress HTTPS 구성(WordPress 사이트 전체에 TLS 적용)

설정에 따라 WordPress 웹사이트에서 TLS를 적용하는 몇 가지 방법이 있습니다. 대부분의 경우 모든 HTTP 트래픽을 HTTPS로 리디렉션하도록 웹 서버를 구성합니다(Mozilla의 SSL 구성 생성기 참조).

또한 HTTPS에서 수신 대기하도록 WordPress를 구성해야 합니다. Really Simple SSL 또는 WP force SSL과 같은 플러그인을 사용하면 그렇게 할 수 있습니다. 이 예에서는 추가 플러그인을 사용하지 않고 이 작업을 수행하는 방법을 살펴보겠습니다.

웹 서버 구성

주의

  • 웹 서버 구성을 복사/붙여넣기할 때 주의하고 웹 서버 설명서를 참조하여 해당 구성이 수행하는 작업을 정확히 알고 있는지 확인하십시오.
  • %{HTTP_HOST}(Apache HTTP Server) 또는 $http_host(Nginx)를 사용하여 온라인에서 많은 예를 찾을 수 있습니다. 둘 다 웹사이트를 HTTP 호스트 헤더 공격에 취약하게 만들 수 있습니다. 대신 표시된 대로 구성에 호스트 이름을 입력하십시오. 아래에.

Nginx를 사용하는 경우 다음을 구성할 수 있습니다.

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

또는 Apache HTTP Server를 사용하는 경우 다음을 구성할 수 있습니다.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://www.example.com%{REQUEST_URI} [L,R=301]
<IfModule>

WordPress URL을 HTTPS로 구성

웹 서버에서 HTTPS를 활성화하면 WordPress도 설정해야 합니다. 이론상 수동으로 할 수 있습니다. WordPress 일반 설정에서 WordPress 주소와 사이트 주소를 변경하기만 하면 됩니다. 또한 모든 웹 사이트 링크를 HTTP에서 HTTPS로 변경하려면 데이터베이스에서 검색 및 교체를 수행해야 합니다.

[스크린샷]

따라서 플러그인을 사용하여 WordPress 웹사이트를 HTTPS로 전환하는 것이 훨씬 쉬울 것입니다. 프로세스를 진행하는 데 도움이 되는Really Simple SSL과 같은 인기 있는 플러그인을 사용할 수 있습니다.

WordPress 대시보드에서 TLS 시행

TLS는 사용 중인 경우에만 유용합니다. 따라서 WordPress 사이트가 TLS를 지원할 뿐만 아니라 시행하는지 확인하고 싶습니다. WordPress 대시보드는 항상 HTTPS를 통해 액세스해야 하므로 WordPress에는 wp-config.php에서 true로 설정할 수 있는 특수 구성 옵션 FORCE_SSL_ADMIN이 포함되어 있습니다.

define('FORCE_SSL_ADMIN', true);

주의

  • 웹 사이트 설정 및 구성(특히 역방향 프록시를 사용하는 경우)에 따라 WordPress 대시보드에 대한 요청이 무한 리디렉션 루프에 들어갈 수 있습니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 WordPress 설명서를 참조하고 프로덕션으로 롤아웃하기 전에 항상 스테이징 환경에서 변경 사항을 테스트하십시오.
  • 또한 FORCE_SSL_ADMIN을 true로 설정하기 전에 이미 TLS를 구성하고 올바르게 작동하는지 확인하십시오.

보너스 팁 1: HSTS(HTTP Strict Transport Security) 추가

모든 트래픽을 HTTPS로 리디렉션하는 것은 훌륭한 조치이지만 불행히도 공격자는 여전히 몇 가지 속임수를 가지고 있을 수 있습니다. SSL 스트립으로 알려진 공격을 통해 공격자는 브라우저가 보안 HTTPS 대신 HTTP로 사이트를 탐색하도록 속여서 사용자의 노력을 효과적으로 무력화할 수 있습니다.

SSL 스트립 공격에 대한 (고도의) 자세한 내용은 아래에서 Moxie Marlinspike의 강연을 시청하십시오.

결과적으로 브라우저는 이제 HTTP Strict Transport Security 또는 HSTS를 구현합니다. HSTS는 이 특정 웹사이트가 HTTP를 통해 액세스되어서는 안 된다고 브라우저에 알려주는 단순한 HTTP 헤더에 불과하며 SSL 스트립 공격을 무력화합니다.

웹 서버에서 HSTS 구성

주의

  • HTTPS에 확신이 생길 때까지 HSTS를 활성화하지 마십시오. 이 HTTP 헤더를 수신하는 모든 방문자는 HTTPS를 통해서만 사이트를 볼 수 있습니다.
  • 항상 max-age 속성을 설정합니다. 선택적으로 HSTS를 처음 배포할 때 값을 낮게 설정하고(잠재적인 문제를 제한하기 위해) HSTS를 사용하는 것이 더 확실할 때 값을 높일 수 있습니다.

Nginx를 사용하는 경우 포트 443에서 수신 대기하는 서버 블록 내에서 다음을 구성할 수 있습니다.

# HSTS (ngx_http_headers_module is required) (63072000 seconds)
add_header Strict-Transport-Security "max-age=63072000" always;

또는 Apache HTTP Server를 사용하는 경우 포트 443에서 수신하는 VirtualHost 내에서 다음을 구성할 수 있습니다.

# HTTP Strict Transport Security (mod_headers is required) 
(63072000 seconds)
Header always set Strict-Transport-Security "max-age=63072000"

보너스 팁 2: TLS 암호 구성

브라우저와 서버 간의 안전한 데이터 전송을 보장하기 위해 양 당사자는 인증, 암호화 및 MAC(메시지 인증 코드) 알고리즘의 조합인 암호 제품군을 사용하여 보안 설정을 협상하는 데 동의합니다. , 데이터를 안전하게 전송합니다.

불행히도 많은 레거시 암호에는 보안 취약성이 있으며 더 이상 사용하기에 특히 안전하지 않습니다. 어떤 암호를 사용할지 결정하는 것은 까다로운 일이지만 Mozilla SSL Configuration Generator를 사용하면 요구 사항에 맞는 TLS 암호 제품군을 쉽게 선택할 수 있습니다. 가능하면 최신 또는 중간 프로필을 사용해 보십시오. 그러나 사용 사례에 따라, 특히 레거시 브라우저를 지원해야 하거나 규정 및 규정 준수 요구 사항을 충족해야 하는 경우 약간 다른 암호 제품군 구성을 사용해야 할 수도 있습니다.

Nginx를 사용하는 경우 다음 TLS 암호를 구성할 수 있습니다(Mozilla SSL 구성 생성기 중간 프로필 기반).

 # intermediate configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES25
6-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDH
E-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

또는 Apache HTTP Server를 사용하는 경우 다음 TLS 암호를 구성합니다(Mozilla SSL 구성 생성기 중간 프로필 기반).

# intermediate configuration
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

더 많은 기술적 통찰력을 얻기 위해 SSLabs라는 무료 도구를 사용하여 웹사이트의 TLS 구성 점수를 테스트할 수도 있습니다.

내 WordPress는 HTTPS에서 실행됩니다. 안전한가요?

녹색 자물쇠 아이콘과 브라우저의 주소 표시줄 옆에 있는 "보안"이라는 단어는 HTTPS가 모든 웹사이트 보안 문제를 해결하는 마법의 지팡이라고 믿게 만들 수 있습니다. 불행히도 그렇지 않습니다. 브라우저 표시줄의 녹색 자물쇠

HTTPS는 WordPress 보안의 일부일 뿐입니다. HTTPS를 사용하면 방문자가 보안 연결 을 통해 웹사이트를 탐색할 수 있습니다. 그러나 WordPress 방화벽처럼 웹 사이트를 보호하거나 더 안전하게 만들지는 않습니다. HTTP에서 실행되는 웹 사이트보다 더 안전하다는 의미는 아닙니다. 다른 보안 방어와 마찬가지로 HTTPS는 문제의 일부 를 해결하는 데 도움이 됩니다.

즉, HTTPS를 구현하고 시행해야 하지만 안심하고 다시는 보안에 대해 걱정할 필요가 없다는 의미는 아닙니다. 여전히 다음을 수행해야 합니다.

  • 이중 인증 추가
  • 파일 무결성 모니터링 플러그인 설치
  • 강력한 WordPress 비밀번호 정책 시행
  • 웹 사이트에서 발생하는 모든 변경 사항의 기록으로 WordPress 활동 로그를 유지하십시오.
  • 좋은 방화벽을 사용하십시오.