HTTPS 의 7 가지 오해

오해 7:HTTPS 캐 시 할 수 없 음
많은 사람들 이 보안 상의 이유 로 브 라 우 저가 로 컬 에 HTTPS 캐 시 를 저장 하지 않 을 것 이 라 고 생각한다.실제로 HTTP 헤더 에 특정 명령 을 사용 하면 HTTPS 는 캐 시 할 수 있다.
마이크로소프트 IE 프로젝트 매니저Eric Lawrence는 다음 과 같이 말 했다.
"HTTP 헤드 가 이렇게 할 수 있다 면 모든 버 전의 IE 가 HTTPS 내용 을 캐 시 하 는 것 은 충격 적일 수 있 습 니 다."예 를 들 어 헤더 명령 이 Cache-Control:max-age=600 이면 이 웹 페이지 는 IE 캐 시 로 10 분 동안 캐 시 됩 니 다.IE 의 캐 시 정책 은 HTTPS 프로 토 콜 을 사용 할 지 여부 와 무관 합 니 다.(다른 브 라 우 저의 행동 은 일치 하지 않 습 니 다.당신 이 사용 하 는 버 전에 달 려 있 기 때문에 여 기 는 토론 하지 않 습 니 다.)"
Firefox 는 기본적으로 메모리 에 만 HTTPS 를 캐 시 합 니 다.단,헤더 명령 에 Cache-Control:Public 만 있 으 면 캐 시 는 하 드 디스크 에 기 록 됩 니 다.아래 그림 에 따 르 면 Firefox 의 하 드 디스크 캐 시 에는 HTTPS 내용 이 있 고 머리 명령 은 바로 Cache-Control:Public 입 니 다.

SSL 인증서 비싸요.
인터넷뒤 져 보다에서 저렴 한 SSL 인증 서 를 많이 발견 할 수 있 습 니 다.1 년 에 10 달러 정도 입 니 다.이것 은 도 메 인 이름 의 연간 요금 과 차이 가 많 지 않 습 니 다.그리고 실제로 SSL 인증서공짜도 찾 을 수 있다.
효력 에 있어 서 저렴 한 인증 서 는 당연히 큰 기관 에서 발급 한 인증서 보다 조금 떨 어 지지 만 거의 모든 주류 브 라 우 저 는 이 인증 서 를 받는다.
오해 5:HTTPS 사이트 에는 고유 한 IP 주소 가 있어 야 합 니 다.
IPv 4 가 분 배 될 예정 이기 때문에 많은 사람들 이 이 문제 에 관심 을 가지 고 있다.IP 주소 마다 SSL 인증서 한 장 만 설치 할 수 있다 는 것 은 의심의 여지 가 없다.단,하위 도 메 인 이름 마스크 SSL 인증서(wildcard SSL certificate,가격 은 연간 125 달러)를 사용 하면 한 IP 주소 에 여러 개의 HTTPS 하위 도 메 인 이름 을 배치 할 수 있 습 니 다.예컨대https://www.httpwatch.com화해시키다https://store.httpwatch.com같은 IP 주 소 를 공유 합 니 다.

또한 UCC(통합 통신 인증서,Unified Communications Certificate)는 하나의 인증서 가 여러 사이트 와 동시에 일치 하 는 것 을 지원 하 며 완전히 다른 도 메 인 이름 일 수 있 습 니 다.SNI(서버 이름 표시,Server Name Indication)는 IP 주소 에 여러 개의 도 메 인 이름 으로 여러 개의 인증 서 를 설치 할 수 있 도록 합 니 다.서버 쪽,Apache,Nginx 는 이 기술 을 지원 하고 IIS 는 지원 하지 않 습 니 다.클 라 이언 트,IE 7+,Firefox 2.0+,Chrome 6+,Safari 2.1+와 Opera 8.0+지원.
오해 4:서버 를 옮 길 때 새 인증 서 를 구 매해 야 합 니 다.
SSL 인증 서 를 배치 하려 면 다음 과 같은 몇 단계 가 필요 합 니 다.
1.서버 에 CSR 파일(SSL 인증서 요청 파일,SSL Certificate Signing Request)을 생 성 합 니 다.
2.CSR 파일 을 사용 하여 SSL 인증 서 를 구 매 합 니 다.
3.SSL 인증 서 를 설치 합 니 다.
이런 절 차 는 모두 심혈 을 기울 여 설계 하여 전송 의 안전 을 확보 하고 누군가가 증 서 를 캡 처 하거나 불법 으로 얻 는 것 을 방지한다.결 과 는 두 번 째 단계 에서 받 은 인증 서 를 다른 서버 에 사용 할 수 없다 는 것 이다.만약 당신 이 이렇게 해 야 한다 면,반드시 다른 형식 으로 인증 서 를 출력 해 야 합 니 다.
예 를 들 어 IIS 의 방법 은 옮 길 수 있 는.pfx 파일 을 만 들 고 암호 로 보호 하 는 것 이다.

이 파일 을 다른 서버 에 전송 하면 원래 SSL 인증 서 를 계속 사용 할 수 있 습 니 다.
오해 3:HTTPS 가 너무 느 려 요.
HTTPS 를 사용 하면 웹 사 이 트 를 더 빨리 만 들 지 는 않 을 것 입 니 다(실제로 가능 합 니 다.다음 글 을 보십시오).그러나 일부기교.는 추가 비용 을 크게 줄 일 수 있 습 니 다.
우선 텍스트 내용 을 압축 하면 디 코딩 에 소모 되 는 CPU 자원 을 낮 출 수 있다.그러나 현대 CPU 로 서 는 이 정도 비용 은 언급 할 가치 가 없다.
그 다음으로 HTTPS 연결 을 구축 하고 추가 TCP 왕복 을 요구 하기 때문에 보 내 고 받 는 바이트 가 추 가 됩 니 다.그러나 아래 그림 에서 볼 수 있 듯 이 새로 추 가 된 바이트 가 매우 적다.

웹 페이지 를 처음 열 었 을 때 HTTPS 프로 토 콜 이 HTTP 프로 토 콜 보다 느 린 것 은 SSL 인증 서 를 읽 고 검증 하 는 시간 때문이다.다음은 HTTP 홈 페이지 가 열 린 시간의 폭포 그림 입 니 다.

같은 웹 페이지 에서 HTTPS 프로 토 콜 을 사용 한 후 열 리 는 시간 이 길 어 졌 다.

연결 을 만 드 는 부분 은 약 10%느 렸 다.그러나 유효한 HTTPS 연결 이 구축 되 고 웹 페이지 를 새로 고침 하면 두 프로 토 콜 은 거의 다 르 지 않다.먼저 HTTP 프로 토 콜 의 새로 고침 표현:

그리고 HTTPS 프로 토 콜:

일부 사용자 들 은 HTTP 보다 HTTPS 가 더 빠르다 는 것 을 발견 할 수 있 습 니 다.이것 은 일부 대기업 의 내부 랜 에서 발생 할 수 있다.왜냐하면 일반적인 상황 에서 회사 의 게 이 트 웨 이 는 모든 네트워크 통신 을 차단 하고 분석 하기 때문이다.그러나 HTTPS 연결 을 만 났 을 때 HTTPS 가 해석 되 지 않 기 때문에 바로 놓 을 수 밖 에 없습니다.바로 이 해석 과정 이 없어 서 HTTPS 가 빨 라 졌 다.
오해 2:HTTPS,Cookie,검색 문자열 이 있 으 면 안전 합 니 다.
HTTPS 데이터 에서 쿠키 와 검색 문자열 을 직접 읽 을 수 는 없 지만 값 을 예측 하기 어렵 게 만들어 야 합 니 다.
예 를 들 어 한 영국 은행 이 순서대로 배 열 된 수 치 를 사용 하여 session id 를 표시 한 적 이 있다.

해커 는 먼저 계 정 을 등록 하고 이 쿠키 를 찾 아 이 값 의 표시 방법 을 볼 수 있다.그리고 쿠키 를 변경 하여 다른 사람의 session id 를 납치 합 니 다.검색 문자열 에 대해 서도유사 방식을 통 해 누설 할 수 있다.
오해 1:로그 인 페이지 를 등록 해 야 HTTPS 가 필요 합 니 다.
이런 생각 은 매우 보편적이다.사람들 은 HTTPS 가 사용자 의 비밀 번 호 를 보호 할 수 있 을 뿐만 아니 라 필요 하지 않다 고 생각한다.Firefox 브 라 우 저의 새 플러그 인Firesheep은 이런 생각 이 틀 렸 다 는 것 을 증명 했다.트 위 터 와 페 이 스 북 에서 다른 사람 을 납치 하 는 세 션 은 매우 쉽다 는 것 을 알 수 있다.
카페 의 무료 와 이 파 이 는 이상 적 인 납치 환경 입 니 다.두 가지 이유 로:
1.이런 와 이 파 이 는 암호 화 되 지 않 기 때문에 모든 데 이 터 를 감시 하기 쉽다.
2.와 이 파 이 는 보통 NAT 를 사용 하여 외부 네트워크 와 내부 네트워크 의 주소 전환 을 하고 모든 내부 네트워크 클 라 이언 트 는 하나의 외부 네트워크 주 소 를 공유 합 니 다.납 치 된 세 션 이 원래 로그 인 자 처럼 보 인 다 는 뜻 이다.
트 위 터 의 경우 로그 인 페이지 에 HTTPS 를 사 용 했 지만 로그 인 후 다른 페이지 는 HTTP 로 바 뀌 었 다.이때 쿠키 의 session 값 이 노출 되 었 습 니 다.

즉,이 쿠키 들 은 HTTPS 환경 에서 만들어 지지 만 HTTP 환경 에서 전송 된다 는 것 이다.만약 누군가가 이 쿠키 를 납치 했다 면,그 는 당신 의 신분 으로 트 위 터 에서 발언 할 수 있 을 것 입 니 다.
원문:http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/
번역문:http://www.ruanyifeng.com/blog/2011/02/seven_myths_about_완 일 봉