HTTPS 의 암호 화 알고리즘 을 깊이 설명 하 다.
HTTPS 는 사실 두 부분 으로 구성 되 어 있 습 니 다.HTTP+SSL/TLS,즉 HTTP 에 암호 화 정 보 를 처리 하 는 모듈 을 추가 한 것 입 니 다.서버 와 클 라 이언 트 의 정보 전송 은 모두 TLS 를 통 해 암호 화 되 기 때문에 전 송 된 데 이 터 는 모두 암호 화 된 데이터 입 니 다.
용도 두 가지:하 나 는 정보 채널 을 구축 하여 데이터 전송 의 안전 을 확보 하 는 것 이다.다른 하 나 는 사이트 의 진실성 을 확인 하 는 것 이다.https 사 이 트 를 사용 하면 브 라 우 저 주소 표시 줄 의 잠 금 표 지 를 클릭 하여 사이트 인증 후의 진실 정 보 를 볼 수 있 고 CA 기구 가 발급 한 안전 사인 을 통 해 조회 할 수 있다.
머리말
암호학 은 컴퓨터 과학 에서 매우 광범 위 하 게 사용 되 는데 HTTPS 는 암호학 의 기초 위 에 세 워 진 안전 한 통신 프로 토 콜 이다.HTTPS 는 1994 년 에 인터넷 회사 에서 처음으로 제 기 했 고 현재 많은 인터넷 업 체 의 홍보 아래 HTTPS 는 각종 크 고 작은 사이트 에서 널리 사용 되 고 있다.HTTPS 를 완전히 이해 하기 전에 명문,암호,암호,키,대칭 암호 화,비대 칭 암호 화,요약,디지털 서명,디지털 인증서 등 암호학 과 관련 된 개념 을 알 아야 한다.
암호(암호)
암호학 에서 의 암호(cipher)는 우리 가 일상생활 에서 말 하 는 암호 와 다 릅 니 다.컴퓨터 용어 인'암호 cipher'는 암호 화 나 복호화 에 사용 되 는 알고리즘 입 니 다.우리 가 일상적으로 사용 하 는'암호 password'는 암호 입 니 다.인증 용도 로 사용 되 는 텍스트 문자열 입 니 다.여기 서 우리 가 토론 하고 자 하 는 것 은 전자:cipher 입 니 다.
키(key)
키 는 암호(cipher)알고리즘 을 사용 하 는 과정 에서 입력 한 인자 입 니 다.같은 명문 은 같은 암호 알고리즘 과 다른 키 계산 에서 서로 다른 암호 문 을 만 들 수 있 습 니 다.많은 유명한 암호 알고리즘 이 공개 되 어 있 습 니 다.키 야 말로 비밀문서 의 안전 여 부 를 결정 하 는 중요 한 매개 변수 입 니 다.보통 키 가 길 수록 해독 의 난이도 가 높 습 니 다.예 를 들 어 8 비트 의 키 는 최대 256 가지 상황 이 있 습 니 다.궁 거 법 을 사용 하면 쉽게 풀 수 있 습 니 다.유명한 DES 알고리즘 은 56 비트 의 키 를 사용 합 니 다.현 재 는 안전 한 암호 화 알고리즘 이 아 닙 니 다.주로 56 비트 의 키 가 너무 짧 아서 몇 시간 안에 풀 릴 수 있 습 니 다.키 는 대칭 키 와 비대 칭 키 로 나 뉜 다.
명문
명문(plaintext)은 암호 화 되 기 전의 원시 데이터 이 며,암호 화 는 암호 화(cipher)를 통 해 연산 한 결과 암호 화(ciphertext)되 었 습 니 다.
대칭 키
대칭 키(Symmetric-key algorithm)는 공유 키 암호 화 라 고도 부 릅 니 다.대칭 키 는 암호 화 와 복호화 과정 에서 사용 하 는 키 가 같 습 니 다.흔히 볼 수 있 는 대칭 암호 화 알고리즘 은 DES,3DES,AES,RC5,RC6 입 니 다.대칭 키 의 장점 은 계산 속도 가 빠 르 지만 단점 도 있 습 니 다.키 는 통신 의 양 끝 에서 공유 되 어야 서로 에 게 키 가 무엇 인지 알 수 있 고 모든 클 라 이언 트 가 같은 키 를 공유 하면 이 키 는 만능 열쇠 처럼 하나의 키 로 모든 사람의 비밀 문 서 를 풀 수 있 습 니 다.모든 클 라 이언 트 와 서버 가 키 를 따로 지 키 면 서버 에서 관리 해 야 할 키 는 수천 만 개 에 달 하 며 서버 에 악몽 을 가 져 옵 니 다.다음은 간단 한 대칭 암호 화로 명문 을 ASCII 로 암호 화한 다.
# : ASCII +
def encipher(plain_text, key):
#
cipher_text = []
for c in plain_text:
cipher_text.append(str(ord(c) + key))
return ' '.join(cipher_text)
def decipher(cipher_text, key):
#
plain_text = []
for c in cipher_text.split(" "):
plain_text.append(chr(int(c)+key))
return "".join(plain_text)
if __name__ == '__main__':
print "cipher_text:", encipher("abcdef", 0)
print "plain_text:", decipher("97 98 99 100 101 102", 0)
비대 칭 키비대 칭 키(public-key cryptography)는 공개 키 암호 화 라 고도 부 릅 니 다.서버 에 서 는 한 쌍 의 키 를 만 들 고 하나의 비밀 키 는 서버 에 저 장 됩 니 다.자신 만 알 고 있 습 니 다.다른 하 나 는 공개 키 입 니 다.공개 키 는 누구나 사용 할 수 있 습 니 다.클 라 이언 트 의 명문 은 공개 키 를 통 해 암호 화 된 비밀문 은 비밀 키 로 복호화 해 야 합 니 다.비대 칭 키 가 암호 화 와 복호화 과정 에서 사용 하 는 키 는 서로 다른 키 이 고 암호 화 와 복호화 가 비대 칭 이기 때문에 비대 칭 암호 화 라 고 합 니 다.대칭 키 암호 화 에 비해 비대 칭 암호 화 는 클 라 이언 트 와 서버 사이 에서 키 를 공유 할 필요 가 없습니다.비밀 키 가 사용자 에 게 보 내지 않 으 면 공개 키 가 인터넷 에서 캡 처 되 더 라 도 복호화 되 지 않 고 훔 친 공개 키 만 쓸모 가 없습니다.흔히 볼 수 있 는 비대 칭 암호 화 는 RSA,비대 칭 복호화 과정 이 있 습 니 다.
데이터 가 브 라 우 저 와 서버 사이 에서 전 송 될 때 전송 과정 에서 사칭 한 도둑 이 내용 을 바 꿀 수 있 습 니 다.그러면 데이터 가 실제 서버 에서 전송 되 고 바 뀌 지 않도록 어떻게 보장 합 니까?또한 전 송 된 데이터 가 변경 되 지 않도록 어떻게 보장 합 니까?이 두 가지 문 제 를 해결 하려 면 반드시 디지털 서명 을 사용 해 야 합 니 다.디지털 서명 은 일상생활 의 서명 과 같이 계약서 에 당신 의 이름 이 떨 어 지면 법 적 의미 에서 본인 이 서명 한 것 이 확실 합 니 다.이것 은 누구 도 모방 할 수 없 는 것 입 니 다.이것 은 당신 만 의 필적 이기 때문에 누구 도 만 들 수 없습니다.그럼 컴퓨터 에 있 는 숫자 서명 은 어떻게 된 겁 니까?디지털 서명 은 전송 내용 이 실제 서버 에서 보 낸 데이터 인지 검증 하 는 데 사 용 됩 니 다.보 낸 데이터 가 변경 되 었 는 지 여 부 는 이 두 가지 일 을 합 니 다.비대 칭 암호 화 된 응용 장면 입 니 다.그러나 그 는 반대로 비밀 키 로 암호 화하 고 그 와 짝 을 이 루 는 공개 키 를 통 해 복호화 했다.
첫 번 째 단계:서버 에서 메 시 지 를 Hash 처리 한 후에 요약 정보 Digest 를 생 성 합 니 다.요약 정 보 는 비밀 키 private-key 로 암호 화 한 후에 서명 을 생 성 합 니 다.서버 는 서명 을 메시지 와 함께 클 라 이언 트 에 보 냅 니 다.
두 번 째 단계:클 라 이언 트 가 데 이 터 를 받 은 후에 서명 을 추출 하여 Public-key 로 복호화 합 니 다.Digest 2 를 정상적으로 복호화 할 수 있다 면 상대방 이 보 낸 것 임 을 확인 할 수 있 습 니 다.
세 번 째 단계:클 라 이언 트 가 메시지 Text 를 추출 하여 똑 같은 Hash 처 리 를 하고 요약 정보 Digest 1 을 얻 은 다음 에 이전에 복호화 한 Digist 2 와 비교 하면 이들 이 같 으 면 내용 이 변경 되 지 않 았 음 을 나타 낸다.그렇지 않 으 면 내용 이 바 뀌 었 다.텍스트 내용 이 조금 이라도 바 뀌 면 Hash 에서 전혀 다른 요약 정 보 를 낼 수 있 기 때문이다.
디지털 인증서(인증 기관)
디지털 인증 서 는 CA 라 고 부 릅 니 다.권위 있 는 기구 가 특정한 사이트 에 발급 한 인증 증명서 입 니 다.이 증명 서 는 여러분(브 라 우 저)이 인정 한 것 입 니 다.왜 디지털 인증 서 를 사용 해 야 합 니까?디지털 서명 이 있어 도 안전 하지 않 습 니까?이러한 상황 이 있 습 니 다.브 라 우 저 는 모든 실제 서버 가 진실 인지 아 닌 지 확인 할 수 없습니다.간단 한 예 를 들 어 A 공장 이 너희 집에 자 물 쇠 를 설치 하 는 동시에 열 쇠 를 너 에 게 건 네 주 었 습 니 다.열쇠 가 자 물 쇠 를 열 수 있다 면 열쇠 와 자물쇠 가 짝 을 이 루 는 지 확인 할 수 있 습 니 다.만약 에 누군가가 열 쇠 를 바 꾸 거나 자 물 쇠 를 바 꾸 면 문 을 열 수 없습니다.너 는 분명히 도 둑 맞 았 을 것 이라는 것 을 알 고 있 었 다.그러나 누군가가 자물쇠 와 열 쇠 를 다른 표면 으로 바 꾸 면 차이 가 많 지 않 지만 품질 이 많이 떨 어 졌 다.비록 열쇠 와 자물쇠 가 세트 로 되 어 있 지만 이것 이 정말 A 공장 이 너 에 게 준 것 인지 확실 하지 않다.그러면 이때 너 는 품질 검사 부 서 를 찾 아 이 자물쇠 가 정말 A 공장 에서 온 것 인지 아 닌 지 를 검사 할 수 있다.품질 검사 부 서 는 권위 있 는 기구 로 그 가 한 말 은 대중 에 게 인 정 받 을 수 있다(하하).
마찬가지 로 누군가가(장삼)자신의 공개 키 로 실제 서버 를 브 라 우 저 에 보 낸 공개 키 를 교체 하면 장삼 은 자신의 비밀 키 로 같은 절 차 를 밟 아 텍스트 Hash,디지털 서명 을 하고 마지막 에 얻 은 결 과 는 문제 가 없 지만 사실은 브 라 우 저가 본 것 은 실제 서버 가 준 것 이 아니다.장 삼 이 안에서 밖으로(공개 키 에서 비밀 키 로)바 뀌 었 다.그렇다면 현재 사용 하고 있 는 공개 키 가 실제 서버 에서 보 낸 것 이 라 고 어떻게 보장 합 니까?우 리 는 디지털 인증서 로 이 문 제 를 해결 할 것 이다.디지털 인증 서 는 일반적으로 디지털 인증서 인증 기구(Certificate Authority)에서 발급 합 니 다.인증서 에는 실제 서버 의 공개 키 와 사이트 의 다른 정보 가 포함 되 어 있 습 니 다.디지털 인증서 기 구 는 자신의 비밀 키 로 암호 화 된 후에 브 라 우 저 에 보 냅 니 다.브 라 우 저 는 디지털 인증서 기구의 공개 키 를 사용 하여 복호화 한 후에 실제 서버 의 공개 키 를 얻 습 니 다.이 과정 은 모두 가 인정 하 는 인증서 기구 위 에 세 워 진 공개 키 이기 때문에 안전 한 방식 입 니 다.
총결산
이상 은 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 기 를 바 랍 니 다.궁금 한 점 이 있 으 시 면 댓 글 을 남 겨 주 셔 서 저희 에 대한 지지 에 감 사 드 립 니 다.
참고:
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
https://zh.wikipedia.org/wiki/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86
https://zh.wikipedia.org/wiki/%E9%AB%98%E7%BA%A7%E5%8A%A0%E5%AF%86%E6%A0%87%E5%87%86
https://zh.wikipedia.org/wiki/%E8%B3%87%E6%96%99%E5%8A%A0%E5%AF%86%E6%A8%99%E6%BA%96
https://zh.wikipedia.org/wiki/%E6%95%B8%E4%BD%8D%E7%B0%BD%E7%AB%A0
http://www.guokr.com/post/114121/
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
MTLS 사용서버가 인증서로 인증되는 것이 일반적이지만 이 경우 클라이언트도 인증서를 가지고 있습니다. MTLS를 사용하면 서버는 클라이언트가 누구인지 확인할 수 있습니다. 시나리오는 클라이언트(Amy)가 MTLS를 사용하여 서...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.