일반 매개 변수
ssl_certificate 인증 서 는 사실 공개 키 로 서버 를 연결 하 는 모든 클 라 이언 트 에 전 송 됩 니 다.
ssl_certificate_key 비밀 키 는 복호화 에 사용 되 기 때문에 권한 은 보호 되 어야 하지만 nginx 의 메 인 프로 세 스 는 읽 을 수 있 습 니 다. ssl_session_timeout: 클 라 이언 트 는 세 션 캐 시 에 있 는 ssl 매개 변수의 만 료 시간 을 다시 사용 할 수 있 습 니 다. 내부 네트워크 시스템 은 기본 5 분 이 너무 짧 아서 30m 즉 30 분, 심지어 4h 로 설정 할 수 있 습 니 다. sl_session_cache shared:SSL:10m;: ssl / tles 세 션 캐 시 형식 과 크기 를 설정 합 니 다. shared 모든 작업 프로 세 스 간 에 캐 시 를 공유 합 니 다.캐 시 크기 는 바이트 단위 로 지정 합 니 다.1 메가바이트 에 약 4000 개의 session 을 저장 할 수 있다.공유 캐 시 마다 임의의 이름 이 있어 야 합 니 다.같은 이름 의 캐 시 는 여러 가상 서버 에 사용 할 수 있 습 니 다. off session 캐 시 사용 금지: nginx 는 클 라 이언 트 session 이 재 활용 되 지 않 을 수 있 음 을 명확 하 게 알려 줍 니 다. none session 캐 시 사용 이 금지 되 었 습 니 다. nginx 는 클 라 이언 트 session 이 재 활용 될 수 있 음 을 알려 주지 만 실제 적 으로 session 파 라 메 터 를 캐 시 에 저장 하지 않 습 니 다. builtin OpenSSL 에 구 축 된 캐 시;하나의 작업 프로 세 스 만 사용 합 니 다.캐 시 크기 는 session 에서 지정 합 니 다.크기 를 주지 않 으 면 20480 개의 세 션 과 같다.내 장 된 캐 시 를 사용 하면 메모리 조각 이 생 길 수 있 습 니 다. 주의: builtin 과 shared 는 동시에 사용 할 수 있 지만 Nginx 는 공식 적 으로 shared 캐 시 만 사용 하고 built - in 캐 시 를 사용 하지 않 는 성능 이 더 높 을 것 이 라 고 말 합 니 다.설정 사례: ssl_session_cache builtin:1000 shared:SSL:10m; 설정 이 긴 keepalive_timeout 도 ssl 세 션 협상 을 요청 하 는 비용 을 줄 일 수 있 지만 스 레 드 의 병발 수 를 고려 해 야 한다. ssl_protocols 명령 은 특정한 암호 화 프로 토 콜 을 시작 하 는 데 사 용 됩 니 다. nginx 는 1.1.13 과 1.0.12 버 전 이후 기본 값 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 입 니 다. TLSv 1.1 과 TLSv 1.2 는 OpenSSL > = 1.0.1 을 확보 해 야 합 니 다. SSLv 3 는 아직 사용 할 곳 이 많 지만 공격 당 하 는 구멍 이 많 습 니 다. ssl_ciphers 암호 화 세트 를 선택 하면 브 라 우 저가 지원 하 는 세트 (순서 와) 가 다 를 수 있 습 니 다.여기 서 지정 한 것 은 OpenSSL 라 이브 러 리 에서 식별 할 수 있 는 쓰기 입 니 다. openssl -v cipher 'RC4:HIGH:!aNULL:!MD5' (뒤에 지정 한 세트 암호 화 알고리즘) 을 통 해 지원 하 는 알고리즘 을 볼 수 있 습 니 다. 암호 화 세트 사 이 를 콜론 으로 구분 하고 암호 화 세트 앞 에 느낌표 가 있 는 것 은 폐기 해 야 한 다 는 뜻 이다. ssl_prefer_server_ciphers on 협상 암호 화 알고리즘 을 설정 할 때 클 라 이언 트 브 라 우 저의 암호 화 세트 가 아 닌 우리 서버 의 암호 화 세트 를 우선 사용 합 니 다. HSTS (HTTP Strict Transport Security, 엄격 한 전송 보안)
HSTS 는 쉽게 말 하면 일정 시간 동안 클 라 이언 트 에 게 HTTPS 를 사용 하여 페이지 에 접근 하도록 강제 하 는 것 이다.원 리 는 다음 과 같다. 서버 응답 헤더 에 Strict - Transport - security 를 추가 하면 max - age 를 설정 할 수 있 습 니 다.
사용자 가 방문 할 때 서버 에서 이 머리 를 심 습 니 다 다음 에 HTTP 를 사용 하면 max - age 가 만 료 되 지 않 으 면 클 라 이언 트 가 내부 로 이동 합 니 다. 307 Redirect Internel 의 응답 코드 를 볼 수 있 습 니 다. (클 라 이언 트 브 라 우 저 에 해당 하 는 것 을 주의 하 십시오. 여기 서 서버 에 302 점프 를 절약 하 였 습 니 다) HTTPS 액세스 소스 서버 로 변경 이 과정 은 중개인 이 80 포트 에 대한 납 치 를 효과적으로 피 했다.그러나 여기에 문제 가 존재 합 니 다. 만약 에 사용자 가 납치 상태 에 있 고 소스 서버 에 접근 한 적 이 없다 면 소스 서버 는 클 라 이언 트 에 Strict - Transport - security 응답 헤드 를 심 어 줄 방법 이 없습니다 (모두 중개인 에 의 해 가 려 졌 습 니 다).어떻게 해결 합 니까? 주의해 야 할 것 은 preload (미리 불 러 오기) 를 사용 한 후에 야 엄격 한 의미 에서 안전 한 HTTPS 입 니 다.그렇지 않 으 면 가장 약 한 부분 에서 무 너 질 수도 있다.예 를 들 면: SSL 연결 을 허용 하지만 HTTP 에서 HTTPS 로 강제로 이동 하지 않 습 니 다. 사용자 가 HTTP 에 접근 하면 납 치 됩 니 다 HSTS 가 배 치 됐 지만 사용자 의 첫 번 째 방문 은 HTTP 의 것 이 었 고 Strict - Transport - security 의 응답 헤드 가 작 동 할 기회 가 없 었 으 며 납 치 됐 습 니 다. OSCP Stapling
저희 가 HTTPS 를 통 해 사 이 트 를 방문 할 때 클 라 이언 트 는 인증서 발급 기관의 인증서 취소 목록 (CRL) 이나 디지털 인증서 온라인 상태 프로 토 콜 (OCSP) 을 통 해 사이트 서버 의 인증서 가 유효한 지 기록 합 니 다.이전 인증 방식 은 가장 비효 율 적 이 었 다. CA 는 CRL 파일 에 인증서 취소 기록 을 계속 추가 하고 CRL 파일 은 점점 커지 며 클 라 이언 트 는 검증 하기 전에 CRL 파일 을 다운로드 하 는 데 시간 이 오래 걸 렸 다. CRL 검증 방식 에 비해 OCSP 는 더욱 효율 적 이 고 OCSP 는 매번 하나의 기록 만 조회 하고 가 져 옵 니 다.그러나 이러한 기본 적 인 OCSP 를 조회 하 는 클 라 이언 트 는 조회 결과 의 응답 을 받 기 전에 후속 사건 을 계속 막 을 것 이다. 네트워크 상황 이 우려 되 는 상황 에서 (특히 대륙 지역) 장시간 의 페이지 공백 을 초래 할 것 이다.또한 해 킹 이나 조직 이 CA 의 OCSP 에 대해 DDoS 공격 (분포 식 공격 거부) 을 하면 클 라 이언 트 는 OCSP 서버 에서 조회 결 과 를 얻 지 못 하고 인증서 검증 을 완료 하면 클 라 이언 트 는 사이트 가 신뢰 를 받 지 못 함 을 알 릴 수 있다. OCSP Stapling 은 말 그대로 OCSP 인 터 페 이 스 를 조회 하 는 작업 을 서버 에 맡 기 는 것 이다. 서버 는 OCSP 정 보 를 직접 조회 할 수 있 을 뿐만 아니 라 소수의 조회 만 하고 응답 캐 시 를 할 수 있다.클 라 이언 트 가 서버 에 TLS 악수 요청 을 할 때 서버 는 인증서 의 OCSP 정 보 를 인증서 체인 과 함께 클 라 이언 트 에 보 내 클 라 이언 트 인증 에 발생 하 는 차단 문 제 를 피한다.OCSP 응답 은 위조 할 수 없 기 때문에 이 과정 에서 추가 적 인 안전 문제 가 발생 하지 않 습 니 다. 주의해 야 할 것 은 Nginx 는 클 라 이언 트 의 HELLO 악수 정보 에서 OCSP 기록 을 되 돌려 주 고 클 라 이언 트 가 Nginx 에 OCSP 정 보 를 요청 할 때 만 Nginx 는 캐 시 된 OCSP 권위 기록 을 클 라 이언 트 에 보 낼 수 있다 는 것 이다.ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;
resolver 233.5.5.5 233.6.6.6 valid=300s;
resolver_timeout 5s;
캐 시 연결 증명서
캐 시 SSL 연결 증 거 는 잦 은 악수 로 인 한 속도 저하 와 성능 손실 을 피 할 수 있다. TLS 프로 토 콜 은 두 가지 세 션 캐 시 시스템 이 있 습 니 다. 세 션 표지 session ID 와 세 션 기록 session ticket 입 니 다.session ID 는 서버 측 에서 지원 하고 프로 토 콜 의 표준 필드 이기 때문에 기본 적 인 모든 서버 가 지원 합 니 다. 서버 측 에서 세 션 ID 와 협상 한 통신 정 보 를 저장 합 니 다. Nginx 에서 1M 메모 리 는 약 4000 개의 session ID 기기 관련 정 보 를 저장 할 수 있 고 서버 자원 을 많이 차지 합 니 다.session ticket 은 TLS 확장 필드 로 서버 와 클 라 이언 트 가 모두 지원 해 야 합 니 다. 이들 에 비해 협상 정 보 를 저장 하 는 위치 와 방식 이 다 르 고 HTTP 의 session 과 쿠키 와 유사 하 다.존재 하 는 경우, Nginx 우선 sessionticket。 ssl_session_cache shared:SSL:20m;
ssl_session_tickets on;
ssl_session_timeout 60m;
301 점프
https 로 건 너 뛰 기
server {
listen 80;
return 301 https://$host$request_uri;
}
HTTP/2
HTTP / 2 프로 토 콜 자체 가 반드시 SSL 을 켜 라 고 요구 하 는 것 은 아니 지만 대부분의 주류 브 라 우 저 는 SSL 을 사용 해 야 HTTP / 2 를 사용 할 수 있 습 니 다.HTTP / 2 를 사용 하려 면 listen directive 를 listen 443 ssl http2 로 바 꾸 면 됩 니 다.HTTP / 2 는 SPDY 의 진행 버 전 으로 성능 상 HTTP 1.1 에 비해 다 중 재 활용 multiplexing, header 압축 과 바 이 너 리 형식 을 추가 한 것 이 가장 중요 하 다. server {
listen 443 ssl http2;
...
}
