SSL /TLS 2023 년 모범 사례

2023 년에는 SSL /TLS 인증서는 더 이상 선택 사항이 아닙니다, 웹에서 민감한 고객 정보를 직접 처리하지 않는 기업의 경우에도 마찬가지입니다. Google과 같은 검색 엔진은 사이트 보안을 SEO 순위 신호로 사용하고 Chrome과 같은 인기있는 웹 브라우저는 HTTPS를 사용하지 않는 웹 사이트를 사용자에게 경고합니다.

그러나 웹 서버와 응용 프로그램이 SSL /TLS 복잡한 구성과 디자인 선택이 많기 때문에 프로토콜을 올바르게 사용하기가 어려울 수 있습니다. 이 가이드는 SSL /을 설정할 때 유의해야 할 주요 사항에 대한 간략한 개요를 제공합니다.TLS 보안과 성능 모두에 중점을두고 있습니다. 기본 사항으로 만 다루어야 할 사항이 여전히 많으므로 일련의 단계로 분류했습니다.

신뢰할 수있는 인증 기관 (CA)을 선택하십시오

인증서는 인증서를 발급하는 CA만큼만 신뢰할 수 있습니다. 공개적으로 신뢰할 수있는 모든 CA는 주요 운영 체제 및 브라우저 루트 인증서 프로그램에서 자신의 위치를 ​​유지하기 위해 엄격한 타사 감사를 받지만 일부는 다른 CA보다 해당 상태를 더 잘 유지합니다. 다음과 같은 CA를 찾으십시오. SSL.com):

• 공개적으로 신뢰받는 분야에서 대부분의 비즈니스를 수행합니다. PKI. 열악한 보안 관행에 비추어 볼 때 이러한 비즈니스는 가장 많이 잃어 가고 있으며 진화하는 업계 표준에 따라 얻을 수있는 모든 것이 있습니다.
• 사용자 보안 및 개인 정보 보호에 영향을 미치는 취약성 발견에 효율적이고 효과적으로 대응업계와 같은 일련 번호 엔트로피 2019 년 초의 이슈. 같은 산업 포럼 검색 mozilla.dev.security.policy 특정 CA가 역경에 어떻게 반응하는지에 대한 좋은 아이디어를 제공 할 수 있습니다.
• 유용한 제품 및 서비스 제공, EV (Extended Validation) 인증서, 대량 / 자동 인증서 발급 등 직관적 인 API 또는 ACME 프로토콜, 쉬운 인증서 수명주기 관리 및 모니터링 서비스 SUPPORT 광범위한 타사 솔루션 목록과 통합합니다.
• 훌륭한 고객 서비스 및 기술 지원으로 유명합니다. 회사의 웹 사이트를 100 % 안전하게 유지하는 것이 중요하며 일이 잘못되었을 때 전화로 진정한 전문가를 만날 수 있어야합니다.

인증 기관 인증 (CAA)

인증 기관 인증 (CAA) 도메인 이름에 대한 인증서 발급이 허용 된 특정 CA를 지정하여 웹 사이트를 보호하는 표준입니다. CA를 선택한 후에는 다음 사항을 고려해야합니다. CAA 레코드 구성 그것을 승인합니다.

개인 키 생성 및 보안

　 SSL /TLS 프로토콜 ~을 사용하다 키 쌍 인터넷을 통해 전송 된 신원을 인증하고 정보를 암호화합니다. 이 중 하나 ( 공개 키)은 광범위한 배포를위한 것이며 다른 하나는 private key)는 최대한 안전하게 유지해야합니다. 이 키들은 인증서 서명 요청 (CSR). 개인 키와 관련하여 명심해야 할 몇 가지 사항은 다음과 같습니다.

• 강력한 개인 키 사용 : 큰 키는 크랙하기 어렵지만 더 많은 컴퓨팅 오버 헤드가 필요합니다. 현재 최소 2048 비트 RSA 키 또는 256 비트 ECDSA 키가 권장되며, 대부분의 웹 사이트는 이러한 값으로 성능과 사용자 경험을 최적화하면서 우수한 보안을 달성 할 수 있습니다.
  
  참고 : 이 두 알고리즘에 대한 개요는 SSL.com의 기사를 참조하십시오. ECDSA와 RSA 비교.
• 개인 키를 보호하십시오 :
  • 안전하고 신뢰할 수있는 환경 (바람직하게 배포 할 서버 또는 FIPS 또는 Common Criteria 호환 장치)에서 개인 키를 생성하십시오. 어머 놀랐다 CA (또는 다른 사람)가 사용자를 대신하여 개인 키를 생성하도록 허용합니다. SSL.com과 같은 평판이 좋은 공용 CA는 보안 하드웨어 토큰 또는 HSM에서 생성되고 내보낼 수없는 경우가 아니면 개인 키를 생성하거나 처리하도록 제안하지 않습니다.
  • 필요에 따라 개인 키에만 액세스하십시오. 새 키를 생성하고 취소 개인 키 액세스 권한이있는 직원이 퇴사 할 때 이전 키에 대한 모든 인증서.
  • 가능한 한 자주 (적어도 XNUMX 년에 한 번이면 좋을 것임) 인증서를 갱신하고 매번 새로 생성 된 개인 키를 사용하는 것이 좋습니다. 다음과 같은 자동화 도구 ACME 프로토콜 잦은 인증서 갱신을 예약하는 데 유용합니다.
  • 개인 키가 손상되었거나 손상된 경우 취소 이 키에 대한 모든 인증서를 확인하고 새 키 쌍을 생성하고 새 키 쌍에 대한 새 인증서를 발급합니다.

서버 구성

표면에, SSL / 설치TLS 증명서 간단한 작업처럼 보일 수 있습니다. 그러나 웹 서버가 빠르고 안전하고 최종 사용자가 브라우저 오류 및 경고가없는 원활한 경험을 할 수 있도록하기 위해 여전히 많은 구성 결정을 내려야합니다. 다음은 SSL /을 설정하는 데 도움이되는 몇 가지 구성 지침입니다.TLS 서버에서 :

• 모든 호스트 이름이 포함되어 있는지 확인하십시오: 인증서가 사이트의 도메인 이름을 포함합니까? www 접두사? 있습니까 주체 대체 이름 (SAN) 모든 도메인 이름에 대해 인증서가 보호하기위한 것입니까?
• 완전한 인증서 체인 설치: 최종 엔티티 SSL /TLS 인증서는 일반적으로 CA의 루트 키가 아닌 중간 인증서로 서명됩니다. 중간 인증서가 웹 서버에 설치되어 브라우저에 완전한 인증 경로 최종 사용자에 대한 신뢰 경고 및 오류를 방지합니다. CA는 필요한 중간체를 제공 할 수 있습니다. SSL.com의 고객은 중급 인증서 다운로드 여러 서버 플랫폼에 대한 중간 번들을 검색합니다.
• 현재 SSL / 사용TLS 프로토콜 (TLS 1.2 또는 1.3): 2018 년 말 모든 주요 브라우저 공급 업체에서 지원 중단 계획 발표 TLS 1.0 년 상반기 1.1과 2020. Google 사용되지 않는 TLS Chrome 1.0(1.1년 72월 30일 출시)의 v2919 및 v84. Chrome 버전 14(2020년 XNUMX월 XNUMX일 출시) 이상은 이러한 프로토콜에 대한 중간 경고를 표시하며 지원이 예정되어 있었습니다. 완전히 제거됨 2021 년 XNUMX 월. 이전 SSL /의 광범위한 브라우저 지원TLS SSL v3와 같은 버전은 오래 전에 사라졌습니다. 동안 TLS 1.2는 현재 가장 널리 사용되는 SSL /TLS 실험 계획안, TLS 1.3 (최신 버전)은 이미 지원 대부분의 주요 웹 브라우저의 현재 버전에서.
• 보안 암호 제품군의 짧은 목록을 사용하십시오. 128 비트 이상의 암호화를 제공하거나 가능하면 더 강력한 암호화 제품군 만 선택하십시오. NIST (National Institute of Standards and Technology)는 또한 TLS 구현은 DES 암호 (또는 그 변형)를 포함하는 암호 제품군에서 AES를 사용하는 암호 제품군으로 이동합니다. 마지막으로, 잠재적으로 허용 가능한 암호화 제품군의 일부만 사용하면 아직 발견되지 않은 취약점에 대한 공격 표면이 최소화됩니다. SSL.com의 부록 안내 TLS 표준 준수 다음을 사용하여 가장 인기있는 웹 서버 플랫폼에 대한 구성 예를 제공합니다. TLS 1.2.
  
  참고 : 안전하지 않은 더 이상 사용되지 않는 암호 (예 : RC4)를 사용하면 다음과 같은 브라우저 보안 오류가 발생할 수 있습니다. ERR_SSL_VERSION_OR_CIPHER_MISMATCH Chrome에서.
• FS (Forward Secrecy) 사용 : 라고도 완벽한 앞으로 비밀 (PFS), FS는 손상된 개인 키가 이전 세션 키도 손상하지 않도록합니다. FS를 활성화하려면 :
  • 구성 TLS EDCHE (Elliptic Curve Diffie-Hellman) 키 교환 알고리즘을 사용하려면 1.2 (DHE를 폴백으로 사용) 가능하면 RSA 키 교환을 완전히 피하십시오.
  • TLS 1.3. TLS 1.3 모든 사람에게 전진 비밀을 제공합니다 TLS 를 통해 세션 임시 Diffie-Hellman (EDH 또는 DHE) 키 교환 프로토콜.
• 사용 TLS 세션 재개 : 지속적인 TCP 연결을 유지하기 위해 keepalives를 사용하는 것과 마찬가지로 TLS 세션 재개를 통해 웹 서버가 최근 협상 된 SSL /TLS 세션 키 협상의 계산 오버 헤드를 무시하고 세션을 다시 시작하십시오.
• OCSP 스테이플 링 고려: OCSP 스테이플 링 웹 서버는 캐시 된 해지 정보를 클라이언트에 직접 전달할 수 있습니다. 즉, 브라우저가 웹 사이트의 인증서가 해지되었는지 확인하기 위해 OCSP 서버에 연결할 필요가 없습니다. 이 요청을 제거함으로써 OCSP 스테이플 링은 실제 성능 향상을 제공합니다. 자세한 내용은 기사를 읽으십시오. 페이지로드 최적화 : OCSP 스테이플 링.

웹 응용 프로그램 디자인에 모범 사례 사용

보안을 염두에두고 웹 애플리케이션을 디자인하는 것은 서버를 올바르게 구성하는 것만 큼 중요합니다. 다음은 사용자가 노출되지 않도록하는 가장 중요한 사항입니다. 중간에 사람 애플리케이션이 좋은 보안 관행과 함께 제공되는 SEO 이점을 얻습니다.

• 혼합 컨텐츠 제거 : JavaScript 파일, 이미지 및 CSS 파일은 모든 SSL /로 액세스TLS. SSL.com의 기사에 설명 된대로 HTTPS 모든 지역서빙 혼합 된 내용 더 이상 웹 사이트 성능을 향상시킬 수있는 방법이 아니며 브라우저 보안 경고 및 SEO 문제가 발생할 수 있습니다.
• 보안 쿠키 사용 : 설정 Secure 쿠키의 플래그는 보안 채널 (예 : HTTPS)을 통한 전송을 강제합니다. 클라이언트 측 JavaScript가 쿠키를 통해 쿠키에 액세스하지 못하게 할 수도 있습니다. HttpOnly 쿠키를 사용하여 쿠키의 교차 사이트 사용을 제한합니다. SameSite 깃발.
• 타사 코드 평가 : 실수로 취약성 또는 악성 코드를 도입 할 수있는 가능성과 같이 웹 사이트에서 타사 라이브러리를 사용할 때 발생할 수있는 잠재적 위험을 이해해야합니다. 항상 최선을 다해 타사의 신뢰성을 확인하고 HTTPS를 사용하여 모든 타사 코드에 연결합니다. 마지막으로, 웹 사이트의 제 XNUMX 자 요소로부터 얻는 혜택이 위험할만한 가치가 있는지 확인하십시오.

진단 도구로 작업 확인

SSL / 설정 후TLS 서버 및 웹 사이트에서 또는 구성을 변경하는 경우 모든 것이 올바르게 설정되고 시스템이 안전한지 확인하는 것이 중요합니다. 사이트의 SSL / 확인을 위해 다양한 진단 도구를 사용할 수 있습니다.TLS. 예 : SSL Shopper 's SSL 검사기 인증서가 올바르게 설치되었는지, 만료일이 언제인지 알려주고 인증서의 신뢰의 사슬.

혼합 콘텐츠와 같은 보안 문제를 확인하기 위해 사이트를 크롤링하는 다른 온라인 도구 및 응용 프로그램을 사용할 수 있습니다. 내장 된 개발자 도구를 사용하여 웹 브라우저에서 혼합 컨텐츠를 확인할 수도 있습니다.

어떤 도구를 선택하든 SSL / 확인 일정을 설정하는 것도 중요합니다.TLS 설치 및 구성. 귀하의 CA도 이에 대해 도움을 드릴 수 있습니다. 예를 들어, 고객의 편의를 위해 SSL.com은 인증서 만료 임박에 대한 자동 알림을 제공합니다.

HSTS(HTTP Strict Transport Security) 구현

HSTS(HTTP Strict Transport Security)는 프로토콜 다운그레이드 공격 및 쿠키 하이재킹으로부터 웹 사이트를 보호하는 데 도움이 되는 보안 정책 메커니즘입니다. 이를 통해 웹 서버는 웹 브라우저(또는 다른 준수 사용자 에이전트)가 보안 HTTPS 연결을 통해서만 상호 작용하고 비보안 HTTP 프로토콜을 통해서는 상호 작용하지 않아야 함을 선언할 수 있습니다. 이 정책은 "Strict-Transport-Security"라는 HTTP 응답 헤더 필드를 통해 서버에서 사용자 에이전트로 전달됩니다.

구현 HTTP 엄격한 전송 보안(HSTS), 웹 서버 구성에 특수 응답 헤더를 추가해야 합니다.

다음은 단계별 가이드입니다.

1. 사이트가 HTTPS를 지원하는지 확인: HSTS를 활성화하기 전에 사이트에 유효한 SSL 인증서 HTTPS를 통해 콘텐츠를 제공할 수 있습니다. 사이트가 아직 HTTPS용으로 구성되지 않은 경우 다음을 수행해야 합니다. SSL 인증서 받기 이를 사용하도록 서버를 구성하십시오.

헤더는 항상 Strict-Transport-Security "max-age=31536000; includeSubDomains"를 설정합니다.

_{이 줄은 모든 하위 도메인을 포함하여 내년(31,536,000초) 동안 사이트에 대해 항상 HTTPS를 사용하도록 브라우저에 지시합니다.}

2. 구성 테스트: HSTS 헤더를 추가한 후 사이트를 테스트하여 제대로 작동하는지 확인해야 합니다. 사이트를 방문하고 브라우저의 개발자 도구를 사용하여 응답 헤더를 확인하면 됩니다. 설정한 값과 함께 Strict-Transport-Security 헤더가 표시되어야 합니다.
3. 사이트를 HSTS 사전 로드 목록에 추가하는 것을 고려하십시오.: HSTS 사전 로드 목록은 HSTS 사용으로 브라우저에 하드코딩된 사이트 목록입니다. 이것은 HSTS 헤더가 수신되기 전에도 사이트에 대한 첫 번째 연결이 안전하도록 보장하므로 추가적인 보호 수준을 제공합니다. hstspreload.org에서 사이트를 HSTS 사전 로드 목록에 제출할 수 있습니다.

적용 사례: 뉴스 웹사이트는 사용자가 실수로 URL에 "https" 대신 "http"를 입력하더라도 항상 안전하게 연결되도록 보장하고자 합니다. 이 웹사이트는 서버 구성에 Strict-Transport-Security 헤더를 추가하고 긴 max-age를 설정하고 모든 하위 도메인을 포함하여 HSTS를 사용합니다. 이렇게 하면 사용자 에이전트가 항상 HTTPS를 사용하여 연결하도록 지시하여 연결을 HTTP로 다운그레이드하고 쿠키를 훔치려는 공격으로부터 사용자를 보호합니다. 웹 사이트는 또한 추가 보호를 위해 HSTS 사전 로드 목록에 제출합니다.

HTTP 공개 키 고정(HPKP) 구현

HPKP(HTTP Public Key Pinning)는 웹 서버가 특정 암호화 공개 키를 자신과 연결하여 MITM (Man-in-the-Middle) 공격 위조 인증서로.

사용 방법에 대한 간략한 개요는 다음과 같습니다.

1. 고정 정보 생성: HPKP 구현의 첫 번째 단계는 피닝 정보 생성이었습니다. 여기에는 인증서의 공개 키 또는 중간 또는 루트 인증서의 공개 키의 암호화 해시 생성이 포함됩니다.
2. 웹 서버 구성: 다음 단계는 다음을 포함하도록 웹 서버를 구성하는 것이었습니다. 공개 키 핀 HTTP 응답의 헤더. 이 헤더에는 공개 키("핀")의 해시, TTL(브라우저가 정보를 기억해야 하는 기간) 및 선택적으로 보고서 URI(브라우저가 핀 유효성 검사 실패에 대한 보고서를 보내는 위치)가 포함됩니다.
3. 핀 유효성 검사 실패 처리: HPKP를 지원하는 브라우저가 고정된 공개 키 중 하나 이상을 포함하지 않는 인증서 체인을 받은 경우 연결을 신뢰할 수 없는 것으로 간주합니다. 보고서 URI가 지정된 경우 브라우저는 실패 보고서도 해당 URI로 보냅니다.

그러나 오용의 위험과 서비스 거부 가능성으로 인해 HPKP는 대부분의 브라우저에서 더 이상 사용되지 않으며 더 이상 권장되지 않습니다. HPKP를 잘못 구성하면 웹 사이트에 액세스할 수 없는 상황이 발생할 수 있습니다.

적용 사례: 과거에 한 기술 회사는 HPKP를 사용하여 공개 키를 서버에 고정했습니다. 이를 통해 인증 기관(CA)이 손상되고 인증서가 해당 도메인에 대해 실수로 발급된 경우 고정된 키 중 하나와 일치하는 공개 키가 없으면 브라우저가 인증서를 신뢰하지 않습니다. 그러나 웹 사이트에 액세스할 수 없도록 고정된 키에 대한 액세스 권한을 잃지 않도록 매우 주의해야 했습니다. 또한 캐시된 고정 정보를 가진 사용자가 사이트에 액세스할 수 없도록 하기 위해 핀이 만료되기 전에 회전하는 프로세스가 있는지 확인해야 했습니다.

TLS 프로토콜 다운그레이드 공격을 방지하기 위한 폴백 SCSV

TLS 폴백 SCSV(신호 암호 제품군 값)는 프로토콜 다운그레이드 공격을 방지하기 위해 도입된 메커니즘입니다. 이러한 공격은 공격자가 연결 설정 프로세스를 방해하고 클라이언트와 서버가 실제로 지원하는 것보다 덜 안전한 버전의 프로토콜을 사용하도록 속일 때 발생합니다.

구현 방법은 다음과 같습니다. TLS 폴백 SCSV:

1. 서버의 SSL 업데이트/TLS 도서관: 첫 번째 단계는 서버의 SSL/TLS 도서관 지원 TLS 폴백 SCSV. 이 기능은 OpenSSL 1.0.1j, 1.0.0o 및 0.9.8zc에서 도입되었습니다. 다른 SSL/TLS 라이브러리에서 설명서를 확인하거나 개발자에게 문의하십시오.
2. 서버 구성: 일단 서버의 SSL/TLS 도서관 지원 TLS 대체 SCSV를 사용하려면 서버를 구성해야 할 수 있습니다. 정확한 단계는 서버 소프트웨어에 따라 다릅니다. 예를 들어 Apache에서는 다음과 같이 구성 파일에 줄을 추가하거나 수정해야 할 수 있습니다.

SSL 프로토콜 모두 -SSLv2 -SSLv3

이 줄은 SSLv2 및 SSLv3을 제외한 모든 프로토콜 버전을 사용하도록 서버에 지시합니다. 클라이언트와 서버가 모두 지원하는 경우 TLS 1.2이지만 클라이언트가 사용하려고 시도합니다. TLS 1.1(아마도 공격자의 간섭으로 인해) 서버는 이를 폴백 시도로 인식하고 연결을 거부합니다.

3. 서버 테스트: 서버를 구성한 후 올바르게 구현되는지 테스트해야 합니다. TLS 폴백 SCSV. SSL Labs Server Test와 같이 이에 도움이 되는 다양한 온라인 도구가 있습니다.

적용 사례: 글로벌 기업이 사용하는 TLS 내부 통신을 보호하기 위한 Fallback SCSV. 이를 통해 공격자가 강제로 프로토콜 다운그레이드를 시도하면 서버가 이를 인식하고 연결을 거부하여 기업의 민감한 데이터를 보호합니다. 회사의 IT 팀은 정기적으로 서버의 SSL/TLS 최신 보안 기능을 사용하고 있는지 확인하고 온라인 도구를 사용하여 서버를 테스트하고 올바르게 구현하고 있는지 확인하기 위해 라이브러리 및 구성 TLS 폴백 SCSV.

혼합 콘텐츠 문제 방지

혼합 콘텐츠는 보안 HTTPS 연결을 통해 로드된 웹 페이지에 비보안 HTTP 연결을 통해 로드된 이미지, 비디오, 스타일시트 또는 스크립트와 같은 리소스가 포함되어 있을 때 발생하는 보안 위험입니다. 브라우저는 이 혼합 콘텐츠를 차단하거나 사용자에게 경고를 표시하여 사이트 보안에 대한 사용자의 인식을 손상시킬 수 있습니다.

혼합 콘텐츠 문제를 방지하는 방법은 다음과 같습니다.

1. 모든 리소스에 HTTPS 사용: 혼합 콘텐츠를 피하는 가장 간단한 방법은 사이트의 모든 리소스가 HTTPS를 통해 로드되는지 확인하는 것입니다. 여기에는 이미지, 스크립트, 스타일시트, iframe, AJAX 요청 및 사이트에서 사용하는 기타 리소스가 포함됩니다.
2. 사이트 코드 업데이트: 사이트 코드에 리소스에 대한 하드 코딩된 HTTP URL이 포함된 경우 대신 HTTPS를 사용하도록 업데이트해야 합니다. 리소스가 HTTPS를 지원하지 않는 서버에서 호스팅되는 경우 자체 서버에서 리소스를 호스팅하거나 HTTPS를 통해 로드할 수 있는 대체 리소스를 찾아야 할 수 있습니다.
3. Content-Security-Policy 헤더를 보내도록 서버 구성: CSP(Content-Security-Policy) HTTP 헤더를 사용하면 사이트에서 로드할 수 있는 리소스를 제어할 수 있습니다. HTTPS 리소스만 허용하는 CSP 헤더를 설정하면 사이트에 실수로 혼합 콘텐츠가 포함되지 않도록 할 수 있습니다.

적용 사례: 온라인 매거진은 이미지와 스크립트를 포함한 모든 콘텐츠가 HTTPS를 통해 로드되도록 합니다. 이렇게 하면 공격자가 이러한 리소스를 변조하고 잠재적으로 악성 콘텐츠를 주입하는 것을 방지할 수 있습니다. 잡지의 웹 개발자는 정기적으로 사이트의 코드를 검토하여 모든 리소스가 HTTPS를 통해 로드되는지 확인하고 엄격한 Content-Security-Policy 헤더를 보내도록 서버를 구성합니다. 또한 온라인 도구를 사용하여 사이트에서 혼합 콘텐츠 문제를 검색하고 발견한 문제를 수정합니다.

여러 사이트를 호스팅하기 위해 SNI(Server Name Indication) 활용

서버 이름 표시 (SNI) 에 대한 확장입니다. TLS 서버가 동일한 IP 주소 및 포트 번호에 여러 인증서를 제공할 수 있도록 하는 프로토콜입니다. 이는 동일한 서버에서 각각 자체 SSL 인증서가 있는 여러 보안 웹사이트를 호스팅해야 하는 웹 호스팅 공급자에게 특히 유용합니다.

SNI를 사용하는 방법은 다음과 같습니다.

1. 서버 소프트웨어가 SNI를 지원하는지 확인: 첫 번째 단계는 서버 소프트웨어가 SNI를 지원하는지 확인하는 것입니다. Apache, Nginx 및 IIS를 포함한 대부분의 최신 웹 서버는 SNI를 지원합니다.
2. 서버 구성: 다음 단계는 SNI를 사용하도록 서버를 구성하는 것입니다. 여기에는 일반적으로 서버에서 호스팅하려는 각 사이트에 대해 별도의 구성 블록을 추가하고 다음을 지정하는 작업이 포함됩니다. SSL 인증서 각 사이트에 사용합니다. 정확한 단계는 서버 소프트웨어에 따라 다릅니다.
3. 구성 테스트: 서버를 구성한 후에는 SNI를 올바르게 사용하고 있는지 테스트해야 합니다. 서버에서 호스팅하는 각 사이트를 방문하여 올바른 SSL 인증서가 사용되고 있는지 확인하면 됩니다.

적용 사례: 호스팅 제공업체는 SNI를 사용하여 동일한 IP 주소에서 여러 웹사이트에 서비스를 제공합니다. 이를 통해 IP 주소 공간을 효율적으로 사용하고 네트워크 구성을 단순화할 수 있습니다. 각 사이트에 대해 서로 다른 SSL 인증서를 사용하도록 서버를 구성하고 정기적으로 구성을 테스트하여 각 사이트에 올바른 인증서가 사용되고 있는지 확인합니다. 이렇게 하면 모든 사이트가 동일한 IP 주소에서 제공되더라도 각 사이트에 안전하고 신뢰할 수 있는 연결이 보장됩니다.

세션 재개로 성능 최적화

세션 재개는 TLS 클라이언트와 서버가 여러 세션에서 동일한 암호화 키를 사용할 수 있도록 허용하는 프로토콜로 매번 새로운 보안 연결을 설정하는 오버헤드를 줄입니다. 이렇게 하면 특히 클라이언트가 자주 연결을 끊었다가 다시 연결하는 애플리케이션의 경우 성능이 크게 향상될 수 있습니다.

 세션 재개를 사용하는 방법은 다음과 같습니다.

1. 서버 소프트웨어가 세션 재개를 지원하는지 확인: 첫 번째 단계는 서버 소프트웨어가 세션 재개를 지원하는지 확인하는 것입니다. Apache, Nginx 및 IIS를 포함한 대부분의 최신 웹 서버는 이 기능을 지원합니다.
2. 서버 구성: 다음 단계는 세션 재개를 사용하도록 서버를 구성하는 것입니다. 여기에는 일반적으로 세션 캐시를 활성화하고 캐시에 대한 시간 제한 값을 설정하는 작업이 포함됩니다. 정확한 단계는 서버 소프트웨어에 따라 다릅니다.
3. 구성 테스트: 서버를 구성한 후 세션 재개를 올바르게 사용하고 있는지 테스트해야 합니다. 다음을 설정하여 이 작업을 수행할 수 있습니다. TLS 서버에 연결하고 연결을 끊은 다음 다시 연결합니다. 세션 재개가 올바르게 작동하는 경우 두 번째 연결이 첫 번째 연결보다 더 빨리 설정되어야 합니다.

적용 사례: 모바일 앱은 세션 재개를 사용하여 빠르고 안전한 연결을 유지합니다. 이는 네트워크 범위가 불규칙한 지역에서 앱을 사용할 때 특히 유용합니다. 앱이 끊긴 후 보안 연결을 신속하게 다시 설정할 수 있기 때문입니다. 앱 개발자는 세션 재개를 사용하도록 서버를 구성하고 기능이 올바르게 작동하는지 정기적으로 테스트합니다. 이를 통해 앱은 까다로운 네트워크 조건에서도 사용자에게 빠르고 원활한 경험을 제공할 수 있습니다.

OCSP 스테이플링으로 인증서 유효성 확인

OCSP(Online Certificate Status Protocol) 스테이플링은 SSL/TLS 연결의 보안을 유지하면서. 이를 통해 서버는 인증 기관(CA)에서 자체 인증서의 현재 상태를 가져온 다음 해당 상태를 클라이언트에 전달할 수 있습니다. TLS 악수.

OCSP 스테이플링을 구현하는 방법은 다음과 같습니다.

1. 서버 소프트웨어가 OCSP 스테이플링을 지원하는지 확인: 첫 번째 단계는 서버 소프트웨어가 OCSP 스테이플링을 지원하는지 확인하는 것입니다. Apache, Nginx 및 IIS를 포함한 대부분의 최신 웹 서버는 이 기능을 지원합니다.
2. 서버 구성: 다음 단계는 OCSP 스테이플링을 사용하도록 서버를 구성하는 것입니다. 여기에는 일반적으로 서버의 SSL/TLS OCSP 응답을 저장할 서버의 위치를 ​​지정하고 구성합니다. 정확한 단계는 서버 소프트웨어에 따라 다릅니다.
3. 구성 테스트: 서버를 구성한 후에는 서버를 테스트하여 OCSP 스테이플링을 올바르게 사용하고 있는지 확인해야 합니다. 다음을 설정하여 이 작업을 수행할 수 있습니다. TLS 서버에 연결하고 서버에 OCSP 응답이 포함되어 있는지 확인 TLS 악수.

적용 사례: 온라인 소매업체는 OCSP 스테이플링을 사용하여 SSL 인증서 상태를 신속하게 확인합니다. 이를 통해 고객은 항상 안전한 연결을 유지하고 데이터가 안전하다는 것을 신뢰할 수 있습니다. 소매업체의 IT 팀은 OCSP 스테이플링을 사용하도록 서버를 구성하고 기능이 올바르게 작동하는지 정기적으로 테스트합니다. 이는 고객의 신뢰를 유지하고 중요한 데이터를 보호하는 데 도움이 됩니다.

사용 안 함 TLS CRIME 공격 완화를 위한 압축

TLS 압축은 SSL/TLS 네트워크를 통해 전송해야 하는 데이터의 양을 줄임으로써. 하지만 연결이 CRIME(Compression Ratio Info-leak Made Easy) 공격에 취약해 공격자가 암호화된 트래픽의 내용을 유추할 수 있습니다.

비활성화하는 방법은 다음과 같습니다. TLS 압축: 

1. 서버 소프트웨어가 비활성화를 지원하는지 확인 TLS 압축: 첫 번째 단계는 서버 소프트웨어가 비활성화를 지원하는지 확인하는 것입니다. TLS 압축. Apache, Nginx 및 IIS를 포함한 대부분의 최신 웹 서버는 이 기능을 지원합니다.
2. 서버 구성: 다음 단계는 서버를 비활성화하도록 구성하는 것입니다. TLS 압축. 정확한 단계는 서버 소프트웨어에 따라 다릅니다. 예를 들어 Apache에서 다음과 같은 줄을 구성 파일에 추가할 수 있습니다.

SSL압축 해제

이 줄은 SSL/에 대해 압축을 사용하지 않도록 서버에 지시합니다.TLS 연결.

3. 구성 테스트: 서버를 구성한 후 제대로 비활성화되는지 테스트해야 합니다. TLS 압축. 다음을 설정하여 이 작업을 수행할 수 있습니다. TLS 서버에 연결하고 연결이 압축을 사용하지 않는지 확인하십시오.

적용 사례: 금융기관이 비활성화 TLS CRIME 공격으로부터 보호하기 위해 서버에 압축. 이는 계좌 번호 및 거래 세부 정보와 같은 민감한 금융 데이터의 기밀성을 보장하는 데 도움이 됩니다. 기관의 IT 팀은 비활성화하도록 서버를 구성합니다. TLS 압축하고 정기적으로 서버를 테스트하여 이 보안 조치를 올바르게 구현하고 있는지 확인합니다. 이것은 기관의 고객을 보호하고 신뢰를 유지하는 데 도움이 됩니다.

구현 TLS 세션 티켓을 올바르게

TLS 세션 티켓은 TLS 클라이언트와 서버가 전체 핸드셰이크를 수행할 필요 없이 이전 세션을 재개할 수 있도록 하여 성능을 향상시킬 수 있는 프로토콜입니다. 그러나 잠재적인 보안 문제를 방지하려면 올바르게 구현해야 합니다.

올바르게 구현하는 방법은 다음과 같습니다. TLS 세션 티켓:

1. 서버 소프트웨어 지원 확인 TLS 세션 티켓: 첫 번째 단계는 서버 소프트웨어가 다음을 지원하는지 확인하는 것입니다. TLS 세션 티켓. Apache, Nginx 및 IIS를 포함한 대부분의 최신 웹 서버는 이 기능을 지원합니다.
2. 서버 구성: 다음 단계는 다음을 사용하도록 서버를 구성하는 것입니다. TLS 세션 티켓. 여기에는 일반적으로 서버의 SSL/TLS 구성. 정확한 단계는 서버 소프트웨어에 따라 다릅니다.
3. 고유한 세션 티켓 키 사용: 잠재적인 보안 문제를 방지하기 위해 각 서버는 고유한 세션 티켓 키를 사용해야 합니다. 부하 분산 장치를 사용하는 경우 클라이언트가 한 서버에서 발급한 세션 티켓을 사용하여 다른 서버와의 세션을 설정하도록 허용하는 대신 세션 티켓을 기반으로 클라이언트를 배포하도록 로드 밸런서를 구성해야 합니다.
4. 정기적으로 세션 티켓 키 교체: 보안을 더욱 강화하려면 세션 티켓 키를 정기적으로 교체해야 합니다. 이는 종종 서버 소프트웨어 또는 별도의 키 관리 시스템을 사용하여 자동화할 수 있습니다.

적용 사례: 여러 서버를 보유한 대규모 기술 회사는 각 서버가 고유한 세션 티켓 키를 사용하도록 합니다. 이렇게 하면 공격자가 한 서버의 세션 티켓을 사용하여 다른 서버의 사용자로 가장하는 것을 방지할 수 있습니다. 회사의 IT 팀은 다음을 사용하도록 서버를 구성합니다. TLS 세션 티켓을 사용하고 세션 티켓 키를 정기적으로 교체하도록 시스템을 설정합니다. 또한 세션 티켓을 기반으로 클라이언트를 분산하도록 로드 밸런서를 구성하여 시스템 보안을 더욱 강화합니다.

보안 재협상 활성화

보안 재협상은 SSL/TLS 클라이언트나 서버가 새로운 요청을 허용하는 프로토콜 TLS 세션 중간에 악수. 이는 암호화 키를 새로 고치거나 암호화 수준을 변경하는 등 다양한 이유로 유용할 수 있습니다. 그러나 안전하게 처리되지 않으면 공격자가 이를 악용하여 암호화된 통신에 일반 텍스트를 삽입할 수 있습니다.

보안 재협상을 활성화하는 방법은 다음과 같습니다.

2. 서버 소프트웨어가 보안 재협상을 지원하는지 확인: 첫 번째 단계는 서버 소프트웨어가 안전한 재협상을 지원하는지 확인하는 것입니다. Apache, Nginx 및 IIS를 포함한 대부분의 최신 웹 서버는 이 기능을 지원합니다.
3. 서버 구성: 다음 단계는 보안 재협상을 사용하도록 서버를 구성하는 것입니다. 여기에는 일반적으로 서버의 SSL/TLS 구성. 정확한 단계는 서버 소프트웨어에 따라 다릅니다.
4. 구성 테스트: 서버를 구성한 후 보안 재협상을 올바르게 사용하고 있는지 테스트해야 합니다. 다음을 설정하여 이 작업을 수행할 수 있습니다. TLS 서버에 연결한 다음 연결 재협상을 시도합니다.

적용 사례: 소셜 미디어 플랫폼을 통해 안전한 재협상이 가능하여 사용자 데이터를 보호합니다. 이렇게 하면 공격자가 사용자와 서버 간의 암호화된 통신에 악성 콘텐츠를 삽입할 수 없습니다. 플랫폼의 IT 팀은 보안 재협상을 사용하도록 서버를 구성하고 정기적으로 서버를 테스트하여 이 보안 조치를 올바르게 구현하고 있는지 확인합니다. 이는 플랫폼 사용자를 보호하고 신뢰를 유지하는 데 도움이 됩니다.

DoS 공격을 방지하기 위해 클라이언트 시작 재협상 비활성화

클라이언트 시작 재협상은 SSL/TLS 클라이언트가 새로운 요청을 허용하는 프로토콜 TLS 세션 중간에 악수. 그러나 공격자가 서버가 지속적으로 세션을 재협상하도록 강제할 수 있는 경우 과도한 리소스를 소비하고 잠재적으로 서비스 거부(DoS) 공격으로 이어질 수 있습니다.

클라이언트 시작 재협상을 비활성화하는 방법은 다음과 같습니다.

1. 서버 소프트웨어가 클라이언트 시작 재협상 비활성화를 지원하는지 확인: 첫 번째 단계는 서버 소프트웨어가 클라이언트 시작 재협상 비활성화를 지원하는지 확인하는 것입니다. Apache, Nginx 및 IIS를 포함한 대부분의 최신 웹 서버는 이 기능을 지원합니다.
2. 서버 구성: 다음 단계는 클라이언트 시작 재협상을 비활성화하도록 서버를 구성하는 것입니다. 여기에는 일반적으로 서버의 SSL/TLS 구성. 정확한 단계는 서버 소프트웨어에 따라 다릅니다.
3. 구성 테스트: 서버를 구성한 후에는 서버를 테스트하여 클라이언트 시작 재협상을 올바르게 비활성화하는지 확인해야 합니다. 다음을 설정하여 이 작업을 수행할 수 있습니다. TLS 서버에 연결한 다음 연결 재협상을 시도합니다. 서버가 재협상 요청을 올바르게 거부하면 올바르게 구성된 것입니다.

적용 사례: 온라인 게임 플랫폼은 잠재적인 DoS 공격으로부터 보호하기 위해 클라이언트가 시작한 재협상을 비활성화합니다. 이는 잠재적인 공격에도 불구하고 사용자가 플랫폼을 계속 사용할 수 있도록 하는 데 도움이 됩니다. 플랫폼의 IT 팀은 클라이언트가 시작한 재협상을 비활성화하도록 서버를 구성하고 정기적으로 서버를 테스트하여 이 보안 조치를 올바르게 구현하고 있는지 확인합니다. 이는 플랫폼 사용자를 보호하고 신뢰를 유지하는 데 도움이 됩니다.

새로운 취약점에 대한 경고 유지

웹 보안은 끊임없이 변화하는 목표이므로 항상 다음 공격을 주시하고 서버에 보안 패치를 즉시 적용해야합니다. 즉, 정보 보안과 관련하여 곧있을 일을 읽고 연락을 유지하는 것은 물론 소프트웨어 업데이트, 특히 중요한 업데이트를 최신 상태로 유지하는 것을 의미합니다. SSL.com의 웹 사이트 (지금이 글을 읽고있는 곳)은 SSL /에 대한 최신 정보를 유지할 수있는 훌륭한 소스입니다.TLS 그리고 정보 보안.

하지만 어떨까요…?

이 가이드에서 다루는 주제에 대해 더 알고 싶고 새로운 문제와 기술이 발생할 때마다 배우고 싶다면 SSL.com을 검색하고 검색하여 시작할 수 있습니다. 지식, SSL / 분야의 새로운 개발로 매주 업데이트됩니다.TLS 과 PKI. 언제든지 이메일을 통해 지원 담당자에게 언제든지 문의하십시오. Support@SSL.com, 전화로 1-877-SSL-Secure을 클릭하거나이 페이지의 오른쪽 하단에있는 채팅 링크를 클릭하세요.

SSL 인증서에 대한 전문가의 조언을 받으세요.
상담을 위해 양식을 작성하십시오.