A, HTTP 및 기원의 단점 HTTPS

우리는 모든을 알고 HTTP 프로토콜에 전송 웹 콘텐츠의 탄생을위한 초석 같은 네트워크 프로토콜 TCP 프로토콜이다 网络分层模型속하는 应用层协议하나.
보안 관점에서 데이터를 전송하기위한 프로토콜에 내재 된 보안 문제의 사용을 탐험 :
- (1) 평문 (암호화되지 않음)를 사용하여 통신의 콘텐츠는 차단 될 수있다;
- (2)에서, 통신 상대를 인증하지 않고, 따라서 위장 발생할 수;
- (3) 메시지의 전체 라인을 증명할 수, 그것은 변조 할 수있다.
SSL은 HTTP 프로토콜의 보안 문제를 해결하는 1990 년대에 의해, 넷스케이프 (넷스케이프)를 설계 SSL(보안 소켓 레이어) 프로토콜 - 安全套接层프로토콜. 개발 SSL 년이 널리 인터넷에서 사용 후, 이름이 정상화 변경되었습니다 TLS(전송 계층 보안) - 传输层安全프로토콜.
그것은라는 HTTPS것을이되어 HTTP + SSL/TLS함께 사용. 이 솔루션은 데이터 전송에 대한 보안 문제의 HTTP 프로토콜입니다;
원리 : 에서 HTTP 协议层와 TCP传输层사이에 추가 安全层애플리케이션 레이어 데이터 패킷이 전송되기 전에 암호화 그래서 전송 중에 데이터의 무결성을 보장한다.
그래서, 데이터 전송 과정에서 SSL / TLS 데이터 무결성을 보장하기 위해 암호화를 구현하는 방법입니까?
- 여기, 우리는 더 계약의 암호화 로직을 모색 할 필요가있다. 두 가지 암호화 알고리즘입니다 : 즉은, 对称加密하고 非对称加密.

두 대칭 암호화

"대칭 암호화"에 대해 "상호"수학적 연산 (단방향 암호화 콘트라스트가 가역적 암호화 알고리즘)으로 이해 될 수있다. 암호화 즉,이 암호 해독,하지만 암호화 또는 암호 해독 과정을 문제 수, 계산에 관련된 중요한라는 "키"일이 있어야합니다.
대칭 암호화 가장 큰 특징은 : 암호화 및 암호 해독은 "동일한"키를 사용한다는 것입니다. 클라이언트와 서버의 상호 작용 키를 전송합니다 클라이언트에 서버가 필요 암호화 통신에 공통의 "키"를 사용하지만, 그렇게하고 전송시 해당 키를 확인하는 방법 - 키 질문 그래서 보안이? 키가 전송 중 타사 차단을 입은 경우, 수단은 통신을 두 번 끝낸 통신 및 일반 텍스트에 차이점 측면에서 타사에 있습니다. 즉 대칭 암호화 키 시나리오가 네트워크를 필요로 적용되지 않습니다.

따라서,이 탄생했습니다 非对称加密! ! !

세, 비대칭 암호화

암호화 키와 복호화에 사용되는 소위 "비대칭 암호화는"2 단자 암호화 통신의 각 제조 양면 통신 공개 키와 개인 키 및 공개 키 교환 다르다. 아래의 클라이언트 서버 공개 키, 데이터 통신에 사용되는 클라이언트의 공개 키를 암호화 할 때와 같이, 경우에도 암호 해독 키는 항상 서비스에 저장되기 때문에 전송시 타사 공개 키 만남 차단, 그래서 차단하는 유일한 방법은 공개 키를 사용하면 해독 할 데이터를 종료하고 공개되지 않습니다.
그러나 이러한 시나리오는 여전히 도청의 몇 가지 위험이 있습니다. 그 후, 클라이언트의 공개 키에 서버 응답을 차단하기 위해 도청으로, 서버, 공공 도청에 대한 클라이언트 응답의 신원을 위조. 암호화 된 데이터의 도청에 사용되는 클라이언트 공개 키 후, 데이터 변조 얻기 위해 일반 텍스트 데이터를 해독하기 위해 자신의 개인 키를 사용하여 데이터 메시지를 차단 도청, 다음 데이터 암호화 및 서버 통신에 서버의 공개 키. 끝이 도청이나 서버로의 통신의 전체 프로세스는, 클라이언트는 자신의 피어 통신을 인식하지 못합니다.
观察下图中的图示模型，假设通信过程已被窃听。那么问题到底出在哪里?
도청 위험은 다음과 같이 비대칭 암호화가 보여
우리는 분석하기 위해 전체 프로세스를 시작할 수 있습니다 :
- 첫 번째 클라이언트는 공개 키 및 응답에서 "피어"에서 얻은 공개 키를 요청합니다. 그런 다음 커뮤니케이션의 "공개 키"를 사용하여. 분명 클라이언트가 아닌 "공개 키"및 검증을하고 "소스"로 - 문제는 이것의 일부입니다. 즉, 클라이언트가 명확하지 않다는 "대중은"서버가 아닌 타사 도청에서 정말 사실이다.
- 그 후, "공개 키"의 검증을 수행해야 클라이언트가 더블 종료 통신의 안전을 보장하기 위해, 공개 키가 정말 합법적 인 서버임을 확인합니다.

네, CA 인증 메커니즘

그것은 타사 조직의 도입해야한다 :
- 证书颁发机构CA(인증 기관) : 예 颁发数字证书的机构. 그것은 발행과 대중 시스템의 공공 검사의 정당성에 대한 책임을 타사을 신뢰할 수있는 디지털 인증서, 전자 상거래를 관리하는 책임을 맡은 기관이다.
- CA 센터는 공개 키 인증서에 나열된 사용자의 공개 키의 정당성을 증명 디지털 인증서의 역할을 사용하여 각 사용자에 대한 디지털 인증서를 발급됩니다. CA의 디지털 서명 메커니즘은 공격자가 위조 인증서 위조 할 수 없습니다 수 있습니다. 즉, 인증서는 한 인증서가 유효하고 합법적으로 다음 인증서의 공개 키가 유효하고 합법적, 변조 될 수 없다!
- 서버는 CA 기관은 서버에 CA 인증서 (인증 서버의 공개 키가 저장되는) 다시 후 자신의 개인 키를 공개 키 암호화 서버를 사용하여 CA의 공개 키를 제공 할 것입니다. 일반 운영 체제 또는 브라우저가 CA 루트 인증서를 지어 질 것이다. 서버에 대한 요청이 서버 CA 인증서를 클라이언트에 제공 할 때 (예 : 브라우저로) 후 클라이언트가 사용하는 클라이언트는 의미의 정당성 서버 CA 인증서하여 루트 CA 인증서 CA 인증서 로컬 인증 (검증에 도달 할 때, 간접 ) 공개 키의 정당성의 소스를 나타냅니다.

다섯째, 자체 서명 된 인증서 장고를 달성하기 위해 + HTTP + SSL

CA 인증서에 대한 공식적인 응용 프로그램이 기관을 필요로하기 때문에,이에, 나는 HTTPS를 통해 장고 서버 기반 통신 간단한 구성의 형태로 자체 서명 된 인증서를 해요.

(1) CA의 프로필에서 발행 한 루트 인증서 만들기 MyCompanyCA.cnf

(2) (서버 CA 인증서를 만들기위한) 프로파일을 확장 만들기MyCompanyLocalhost.ext

(3)는 CA 인증서와 키 생성 (사용하려면 openssl에 필요, 패키지 관리 도구를 통해 설치 될 수 있습니다)

(4), SSL 인증서 및 키 신청 서류를 작성

(5) 발행 SSL 인증서
상기 절차 후에는 OpenSSL 자체 서명 된 인증서를 상기 MyCompanyCA 달성. CA 루트 인증서에 대한 CER (이 때문에 우리의 자체 서명 시스템이나 브라우저, 그리고 루트 인증서가 내장되지 않은, 우리는 수동으로 추가해야합니다). SSL 인증서 파일은 MyCompanyLocalhost입니다. CER, SSL 인증서 키 파일은 MyCompanyLocalhost.pvk입니다.

여섯, 장고 테스트 서버는 HTTPS를 시작합니다

시작 테스트 HTTPS 서버는 다음과 같이 :

(1) 설치 종속성

(2) 구성 파일 장고를 수정

(3), HTTPS 서비스 장고 시작
장고 액세스 HTTPS에 브라우저를 사용할 수 없습니다 아직 HTTPS 서비스를 시작했지만 이후 (서버 인증서는 신뢰할 수 없습니다).

세븐, CA 루트 인증서를 설치

CA는 액세스 클라이언트에 대한 HTTPS의 사용을 필요로하는 설치된 자체 서명 루트 인증서해야합니다. 다음은 (도 인터페이스 윈도우 조작 관련) 운영체제 인증서 도시 맥 OS에 추가된다 :

(1) 루트 인증서를 추가

(2) 인증서를 신뢰하도록 시스템을 설정
그 이후로, 클라이언트 (브라우저) 추가가 완료 중 하나, 당신은 서버에 액세스하는 데 https를 사용 할 수 있습니다.