HTTPS가 연결 보안을 보장하는 방법: 모든 웹 개발자가 알아야 할 사항. HTTPS 프로토콜은 무엇이며 인터넷에서 사용자를 어떻게 보호합니까?

현재 위치: 분류되지 않음

웹사이트 개발,

알고리즘

번역

어쨌든 HTTPS는 어떻게 작동하나요? 이것은 제가 작업 프로젝트에서 며칠 동안 씨름했던 질문입니다.

웹 개발자로서 저는 HTTPS를 사용하여 사용자 데이터를 보호하는 것이 매우 중요하다는 것을 이해했습니다. 좋은 생각, 그러나 HTTPS가 실제로 어떻게 작동하는지 제대로 이해한 적이 없습니다.

데이터는 어떻게 보호되나요? 누군가 이미 자신의 채널을 듣고 있는 경우 클라이언트와 서버는 어떻게 보안 연결을 설정할 수 있습니까? 보안 인증서란 무엇이며 왜 누군가에게 비용을 지불하고 인증서를 받아야 합니까?

관로

작동 방식을 자세히 알아보기 전에 인터넷 연결 보안이 중요한 이유와 HTTPS가 보호하는 대상에 대해 간략하게 설명하겠습니다.

브라우저가 즐겨찾는 웹사이트에 요청할 때 요청은 다양한 네트워크를 거쳐야 하며, 이들 중 하나는 잠재적으로 설정된 연결을 도청하거나 방해하는 데 사용될 수 있습니다.

자신의 컴퓨터에서 자신의 다른 컴퓨터로 로컬 네트워크, 라우터 및 스위치, ISP 및 기타 여러 중간 공급자를 통해 - 엄청난 양조직은 귀하의 데이터를 중계합니다. 공격자가 그 중 하나 이상에 해당하면 어떤 데이터가 전송되고 있는지 확인할 수 있는 기회가 있습니다.

일반적으로 요청은 클라이언트 요청과 서버 응답이 모두 전송되는 일반 HTTP를 사용하여 전송됩니다. 공개 양식. HTTP가 기본적으로 암호화를 사용하지 않는 데에는 여러 가지 좋은 주장이 있습니다.

이를 위해서는 더 많은 컴퓨팅 성능이 필요합니다.
더 많은 데이터가 전송됨
캐싱을 사용할 수 없습니다.

그러나 어떤 경우에는 통신 채널이 독점적으로 전송되는 경우 중요한 정보(예: 비밀번호 또는 데이터 신용 카드), 제공해야합니다 추가 조치, 그러한 연결을 도청하는 것을 방지합니다.

TLS(전송 계층 보안)

이제 우리는 암호화의 세계로 뛰어들 것입니다. 그러나 이에 대한 특별한 경험은 필요하지 않습니다. 우리는 가장 많은 것을 고려할 것입니다 일반적인 질문. 따라서 암호화를 사용하면 연결에 영향을 주거나 단순히 도청하려는 잠재적인 공격자로부터 연결을 보호할 수 있습니다.

SSL의 후속인 TLS는 보안 HTTP 연결(소위 HTTPS)을 제공하는 데 가장 자주 사용되는 프로토콜입니다. TLS는 OSI 모델에서 HTTP 프로토콜 아래 계층에 위치합니다. 간단히 말해서 이는 요청을 실행하는 과정에서 먼저 TLS 연결과 관련된 모든 "사물"이 발생한 다음 HTTP 연결과 관련된 모든 일이 발생한다는 것을 의미합니다.

TLS는 하이브리드 암호화 시스템입니다. 이는 다음에서 살펴볼 여러 암호화 접근 방식을 사용한다는 것을 의미합니다.

1) 공유 비밀 키 생성 및 인증(즉, 본인이 누구인지 확인)을 위한 비대칭 암호화(공개 키 암호화 시스템).
2) 대칭 암호화는 비밀 키를 사용하여 요청과 응답을 추가로 암호화합니다.

공개키 암호화 시스템

공개 키 암호화 시스템은 각 당사자가 공개 키와 키를 모두 갖는 암호화 시스템의 한 유형입니다. 개인 키, 수학적으로 서로 관련되어 있습니다. 공개 키는 메시지 텍스트를 "횡설수설"로 암호화하는 데 사용되는 반면, 개인 키는 원본 텍스트를 해독하고 검색하는 데 사용됩니다.

공개 키를 사용하여 메시지를 암호화한 후에는 해당 개인 키로만 해독할 수 있습니다. 어떤 키도 두 가지 기능을 모두 수행할 수 없습니다. 공개 키는 다음 위치에 게시됩니다. 오픈 액세스시스템이 위협에 노출될 위험이 없지만 개인 키는 데이터를 해독할 권한이 없는 사람의 손에 들어가서는 안 됩니다. 따라서 공개 키와 비공개 키가 있습니다. 비대칭 암호화의 가장 인상적인 이점 중 하나는 이전에 서로를 전혀 인식하지 못했던 두 당사자가 처음에는 개방적이고 보안되지 않은 연결을 통해 데이터를 교환하면서 보안 연결을 설정할 수 있다는 것입니다.
클라이언트와 서버는 자체 개인 키와 공개 키를 사용하여 세션에 대한 공유 비밀 키를 만듭니다.

이는 클라이언트와 서버 사이에 누군가가 연결을 관찰하더라도 여전히 클라이언트의 개인 키, 서버의 개인 키 또는 세션의 비밀 키를 찾을 수 없음을 의미합니다.

이것이 어떻게 가능합니까? 수학!

Diffie-Hellman 알고리즘

가장 일반적인 접근 방식 중 하나는 DH(Diffie-Hellman) 키 교환 알고리즘입니다. 이 알고리즘을 사용하면 클라이언트와 서버가 연결을 통해 비밀 키를 전송할 필요 없이 공유 비밀 키에 동의할 수 있습니다. 따라서 채널을 청취하는 공격자는 예외 없이 모든 데이터 패킷을 가로채더라도 비밀 키를 확인할 수 없습니다.

DH 알고리즘을 사용하여 키가 교환되면 결과 비밀 키를 사용하여 훨씬 간단한 대칭 암호화를 사용하여 해당 세션 내에서 추가 통신을 암호화할 수 있습니다.

약간의 수학 ...

이 알고리즘의 기본이 되는 수학적 함수는 중요합니다. 독특한 특징- 상대적으로 계산하기가 쉽다. 앞으로 방향, 그러나 실제로는 역으로 계산되지 않습니다. 이것은 바로 매우 큰 소수가 작용하는 영역입니다.

Alice와 Bob이 DH 알고리즘을 사용하여 키를 교환하는 두 당사자가 된다고 가정합니다. 먼저 그들은 어떤 근거로든 동의합니다. 뿌리(대개 작은 숫자, 2,3 또는 5와 같은) 및 매우 큰 소수 초기(300자리 이상). 두 값 모두 연결을 손상시킬 위험 없이 통신 채널을 통해 일반 텍스트로 전송됩니다.

Alice와 Bob은 모두 통신 채널을 통해 전송되지 않는 고유한 개인 키(100자리 이상)를 가지고 있다는 점을 기억하십시오.

혼합물은 통신 채널을 통해 전송됩니다. 혼합물, 개인 키와 값에서 파생됨 초기그리고 뿌리.

따라서:
앨리스의 혼합 = (루트 ^ 앨리스의 비밀) % 소수
Bob의 혼합 = (루트 ^ Bob의 비밀) % 소수
여기서 %는 나눗셈의 나머지 부분입니다.

따라서 Alice는 승인된 상수 값을 기반으로 혼합을 생성합니다( 뿌리그리고 초기), Bob도 마찬가지입니다. 일단 값을 얻은 후에는 혼합물서로 추가 수학적 연산을 수행하여 세션의 개인 키를 얻습니다. 즉:

앨리스의 계산
(밥의 혼합물 ^ 앨리스의 비밀) % 소수

밥의 계산
(앨리스의 혼합물 ^ 밥의 비밀) % 프라임

이러한 작업의 결과는 Alice와 Bob 모두에 대해 동일한 번호이며 이 번호는 이 세션의 개인 키가 됩니다. 어느 당사자도 통신 채널을 통해 개인 키를 보낼 필요가 없었으며 결과 비밀 키도 공개 연결을 통해 전송되지 않았습니다. 굉장한!

수학에 익숙하지 않은 사람들을 위해 Wikipedia는 다음을 설명하는 훌륭한 그림을 제공합니다. 이 과정예를 들어 색상 혼합을 사용하면 다음과 같습니다.

시작 색상(노란색)이 어떻게 Bob과 Alice 모두에게 동일한 "혼합" 색상이 되는지 확인하세요. 열린 통신 채널을 통해 전송되는 유일한 것은 반혼합된 색상이며, 이는 실제로 통신 채널을 듣는 누구에게나 의미가 없습니다.

대칭 암호화

키 교환은 연결 설정 중에 세션당 한 번만 발생합니다. 당사자들이 비밀 키에 이미 동의하면 대칭 암호화를 사용하여 클라이언트-서버 상호 작용이 발생합니다. 이는 추가 확인 비용이 필요하지 않기 때문에 정보 전송에 훨씬 효율적입니다.

클라이언트와 서버는 미리 획득한 비밀키와 암호화 모드에 대한 합의를 통해 서로 수신한 메시지를 비밀키로 암호화하고 복호화함으로써 안전하게 통신할 수 있다. 채널에 연결하는 공격자는 네트워크를 통해 앞뒤로 이동하는 "쓰레기"만 볼 수 있습니다.

입증

Diffie-Hellman 알고리즘을 사용하면 두 당사자가 개인 비밀 키를 얻을 수 있습니다. 하지만 양측이 실제로 서로 대화하고 있다는 것을 어떻게 확신할 수 있습니까? 아직 인증에 대해서는 이야기하지 않았습니다.

친구에게 전화해서 DH 키 교환을 했는데 갑자기 내 전화가 도청되어 실제로는 다른 사람과 통화 중이었다는 사실이 밝혀지면 어떻게 될까요?! 나는 여전히 이 사람과 안전하게 의사소통할 수 있을 것입니다. 누구도 우리의 말을 들을 수 없습니다. 그러나 이 사람은 내가 의사소통하고 있다고 생각하는 사람이 아닐 것입니다. 별로 안전하지 않아요!

인증 문제를 해결하려면 주체가 누구인지 확인하는 공개 키 인프라가 필요합니다. 이 인프라는 디지털 인증서를 생성, 관리, 배포 및 취소하도록 설계되었습니다. 인증서는 사이트가 HTTPS를 통해 작동하기 위해 비용을 지불해야 하는 성가신 일입니다.

그런데 인증서란 정확히 무엇이며, 인증서가 어떻게 보안을 제공합니까?

인증서

가장 대략적인 근사치로는, 디지털 인증서전자 디지털 서명(자세한 내용은 잠시 후에 설명)을 사용하고 컴퓨터의 공개(공개) 키를 해당 소유권과 연결하는 파일입니다. 인증서의 디지털 서명은 누군가가 공개 키가 다음에 속한다는 것을 인증한다는 것을 의미합니다. 특정 사람에게또는 조직.

기본적으로 인증서는 바인딩됩니다. 도메인 이름특정 공개 키로. 이렇게 하면 공격자가 클라이언트가 액세스하는 서버를 가장하여 공개 키를 제공할 가능성이 방지됩니다.

위의 전화 예에서 해커는 내 친구인 것처럼 가장하여 자신의 공개 키를 나에게 보여 주려고 할 수 있습니다. 하지만 그의 인증서에 있는 서명은 내가 신뢰하는 사람의 서명이 아닐 것입니다.

웹 브라우저에서 인증서를 신뢰하려면 공인된 인증 기관(CA, CA)의 서명이 있어야 합니다. CA는 수행하는 회사입니다. 수동 확인, 인증서를 취득하려는 사람은 다음 두 가지 조건을 충족해야 합니다.

1. 실제로 존재합니다.
2. 인증서를 얻으려는 도메인에 액세스할 수 있습니다.

CA가 신청자가 실제로 도메인을 제어하고 있음을 확인하면 CA는 해당 사이트에 대한 인증서에 서명하여 사이트의 공개 키가 실제로 해당 사이트에 속하고 신뢰할 수 있다는 사실에 대한 승인 스탬프를 찍습니다.

귀하의 브라우저에는 이미 인증된 CA 목록이 사전 로드되어 있습니다. 서버가 공인 CA에서 서명하지 않은 인증서를 반환하는 경우 큰 빨간색 경고가 나타납니다. 안에 그렇지 않으면, 누구나 더미 인증서에 서명할 수 있습니다.

따라서 해커가 서버의 공개 키를 가져와 이 공개 키가 facebook.com 웹사이트와 연결되어 있음을 확인하는 디지털 인증서를 생성하더라도 인증서가 공인 CA에서 서명한 것이 아니기 때문에 브라우저는 이를 믿지 않습니다.

인증서에 대해 알아야 할 기타 사항

확장된 검증

일반 X.509 인증서 외에도 더 높은 수준의 신뢰를 제공하는 확장 유효성 검사 인증서가 있습니다. CA는 이러한 인증서를 발급함으로써 다음 사항도 커밋합니다. 더 많은 확인증명서를 받는 사람과 관련하여(보통 여권 데이터 또는 계정 사용)

이러한 인증서를 받으면 브라우저는 자물쇠가 있는 일반적인 아이콘 외에 주소 표시줄에 녹색 막대를 표시합니다.

하나의 서버에서 여러 웹사이트 제공

TLS 프로토콜을 사용한 데이터 교환은 HTTP 연결이 시작되기 전에 이루어지기 때문에 여러 웹사이트가 동일한 웹 서버, 동일한 IP 주소에 있는 경우 문제가 발생할 수 있습니다. 가상 호스트 라우팅은 웹 서버에 의해 수행되지만 TLS 연결은 더 일찍 발생합니다. 단일 인증서서버에 있는 사이트를 요청할 때 전체 서버에 대한 정보가 사용됩니다.

사이트와 사용자를 보호하세요

HTTPS란 무엇입니까?

HTTPS(Hypertext Transport Protocol Secure)는 사이트와 사용자 장치 간에 정보를 교환할 때 보안과 개인 정보 보호를 보장하는 프로토콜입니다. 웹사이트 방문자는 자신이 제공하는 데이터가 사기꾼의 손에 들어가지 않을 것이라고 기대합니다. 방문자가 귀하의 사이트에 남기는 데이터를 보호하려면 HTTPS 프로토콜(사이트에 어떤 콘텐츠가 있는지에 관계없이).

HTTPS를 사용하는 웹 페이지에서는 프로토콜을 사용하여 정보의 무결성이 보장됩니다. TLS(전송 계층 보안 - 전송 수준의 보안)은 세 가지 주요 보호 수준을 제공합니다.

암호화가로채기를 피하기 위해 데이터를 전송했습니다. 이로 인해 공격자는 사이트 방문자 간에 어떤 정보가 교환되는지 알아낼 수 없으며, 다른 페이지에서의 활동을 추적하거나 데이터에 액세스할 수 없습니다.
데이터 보안. 전송된 데이터의 변경이나 왜곡은 고의 여부에 관계없이 기록됩니다.
입증방문자가 원하는 사이트에 정확히 접속할 수 있도록 보장하고 중간자 공격으로부터 보호합니다. 사용자는 그러한 사이트를 더 신뢰하며 이로 인해 추가 기능귀하의 비즈니스를 위해.

신뢰할 수 있는 보안 인증서 사용

사이트에서 HTTPS를 사용하기로 결정한 경우 보안 인증서를 얻어야 합니다. 이는 지정된 웹 주소가 실제로 귀하의 조직에 속해 있는지 확인하는 인증 기관에서 발행됩니다. 이를 통해 방문자는 도청 공격으로부터 보호받을 수 있습니다. 높은 수준의 보안을 보장하려면 인증서를 설정할 때 2048비트 키를 선택하세요. 더 약한 키(1024비트)가 포함된 인증서를 이미 사용하고 있는 경우 2048비트 인증서로 교체하세요. 인증서를 선택할 때 아래 지침을 따르십시오.

기술 지원을 제공할 수 있는 신뢰할 수 있는 인증 기관으로부터 인증서를 받으세요.
귀하의 사이트에 어떤 유형의 인증서가 적합한지 결정하십시오.
- 하나의 보호된 소스(예: www.example.com)에 대한 단일 인증서입니다.
- 잘 알려진 여러 보안 소스(예: www.example.com, cdn.example.com, example.co.uk)에 대한 다중 도메인 인증서입니다.
- 여러 동적 하위 도메인이 있는 보안 소스에 대한 템플릿 인증서입니다. (예: a.example.com, b.example.com)

서버 측에서 301 리디렉션 사용

HTTP 주소에 대한 서버 측 301 리디렉션을 사용하여 사용자와 검색 엔진을 HTTPS 지원 페이지나 리소스로 리디렉션합니다.

HTTPS 페이지를 크롤링하고 색인을 생성할 수 있는지 확인하세요.

robots.txt 파일이 HTTPS 페이지를 크롤링하고 색인화하는 것을 방지하지 마십시오.
HTTPS 페이지에 noindex 메타 태그를 배치하지 마세요.
페이지를 크롤링할 수 있는지 확인하려면 URL 검사기 도구를 사용하세요.

HSTS 기술 사용

HTTPS 프로토콜을 사용하는 사이트에서는 HSTS(HTTP Strict Transport Security) 기술을 사용하는 것이 좋습니다. 이 경우 사용자가 주소 표시줄에 http를 입력하더라도 브라우저는 HTTPS 페이지를 요청합니다. Google은 검색결과에 보호된 URL만 제공합니다. 이 모든 것이 사용자에게 보호되지 않은 콘텐츠가 표시될 가능성을 줄여줍니다.

HSTS를 사용하려면 이 기술을 지원하는 웹 서버를 사용하고 해당 설정에서 적절한 기능을 활성화하십시오.

HSTS를 사용하면 롤백 프로세스가 더 어려워지므로 다음을 수행하여 활성화하세요.

HSTS를 활성화하지 않고 HTTPS로 마이그레이션합니다.
다음을 사용하여 HSTS 헤더 전송을 활성화합니다. 최소값최대 연령 지시어. 사용자 및 다른 클라이언트의 트래픽 양은 물론 광고와 같은 종속 개체의 성능도 모니터링합니다.
HSTS 헤더의 max-age 값을 점차적으로 늘립니다.

HSTS가 사용자와 사용자에게 어려움을 주지 않는다면 검색 엔진웹 브라우징 후 해당 사이트를 사전 로드 목록에 추가할 수 있습니다. 가장 널리 사용되는 브라우저는 이 목록을 사용하여 사이트가 안전한지 확인합니다.

HSTS 사전 로드 활성화

일반적인 문제

TLS 보안을 사용할 때 발생할 수 있는 몇 가지 문제와 해결 방법은 다음과 같습니다.

설명	행동
만료된 인증서.	적시에 인증서를 갱신하세요.
인증서에 잘못된 사이트 이름이 포함되어 있습니다.	사이트를 제공하는 모든 호스트 이름에 대한 인증서를 얻었는지 확인하세요. 인증서에 호스트 www.example.com만 나열되어 있다고 가정해 보겠습니다. example.com("www." 접두사 없이)으로 이동하려는 사용자는 인증서 불일치로 인해 해당 사이트에 갈 수 없습니다.
SNI(서버 이름 표시)는 지원되지 않습니다.	웹 서버가 SNI를 지원해야 합니다. 또한 방문자가 지원되는 브라우저를 사용하도록 권장하십시오. SNI는 모든 최신 브라우저에서 지원됩니다. 레거시 브라우저를 지원하려면 전용 IP 주소가 필요합니다.
스캔 문제.	robots.txt 파일을 사용하여 HTTPS 사이트가 크롤링되는 것을 차단하지 마세요.
인덱싱 문제.	가능하다면 검색 엔진이 페이지를 색인화하도록 허용하세요. NOINDEX 메타태그를 사용하지 마세요.
이전 버전의 프로토콜.	이전 버전의 프로토콜은 취약합니다. 사용 최신 버전 TLS 및 프로토콜 라이브러리.
보호된 요소와 보호되지 않은 요소의 조합.	다음을 통해 제공되는 HTTPS 페이지에만 콘텐츠를 삽입할 수 있습니다. HTTP 프로토콜에스.
HTTP 및 HTTPS 페이지의 콘텐츠가 다릅니다.	HTTP 및 HTTPS 페이지의 콘텐츠는 동일해야 합니다.

보안 데이터 전송 프로토콜은 지난 세기에 발명되었으며 오늘날 인터넷을 통해 정보를 교환할 때 가장 널리 사용되는 보호 방법 중 하나입니다. 오늘날 World Wide Web은 모든 사람이 어디에서나 사용하므로 모든 데이터 교환은 안전해야 합니다. 그리고 이를 위해 특별한 것이 만들어졌습니다.보안 데이터 전송 프로토콜.

이는 별도의 프로토콜이 아니라 SSL 또는 TLS 인증서를 통해 작동하는 일반적인 HTTP의 확장이라는 점을 즉시 알아두세요. 하지만 이 프로토콜만이 리소스에 대한 공격으로부터 완전한 보호를 제공할 수 있습니다.

그것은 통해 작동합니다 SSL 인증서. 이는 합법성을 확인하는 사이트의 '전자 여권'과 같습니다. 그리고 다른 문서와 마찬가지로 포털 소유자에 대한 필요한 데이터를 저장하는 문서입니다. 예를 들어:

회사 또는 조직의 이름
회사가 위치한 국가명, 지역, 도시명
인증서가 생성된 사이트를 제공하는 서버의 이름입니다.

보안 데이터 전송 프로토콜은 무엇으로 구성되며 그 유형은 무엇입니까?

데이터 전송 프로토콜 또는 SSL 인증서는 두 가지 주요 요소를 결합합니다.

전문센터를 통한 인증;
암호화(모든 정보는 이해할 수 없는 형식으로 변환되어야 하며 일반적으로 특정 사용자에게만 제공됩니다).

오늘 SSL 보안 인증서를 구매할 수 있습니다 다양한 유형. 제안된 각 옵션에는 고유한 옵션이 있습니다. 강점그리고 특징.

많은 사람들이 단순히 도메인을 검증하는 프로토콜을 구매하기로 결정합니다. 저것들. 이는 클라이언트가 액세스하는 도메인인 이메일 주소의 소유권을 인증합니다. 검증 및 발급을 위해 많은 서류가 필요하지 않기 때문에 비용이 저렴하고 접수 속도가 빠른 것이 장점입니다.

향상된 위임장 인증서는 높은 수준의 암호화가 특징이므로 고객에게 이는 신뢰할 수 있는 보안을 보장합니다. 하지만 이 제품은 이전 제품보다 가격이 더 비쌉니다.

기본 도메인뿐만 아니라 해당 하위 도메인도 보호할 수 있는 옵션이 있습니다. 이것은 가장 비싸지만 가장 신뢰할 수 있는 옵션이기도 합니다.

다중 도메인 인증서는 한 번에 여러 주소의 보안을 보장할 수 있는 유형 중 하나이기도 합니다.

구매에 관심이 있으시면 고품질의 제품, 권장사항을 고려하시기 바랍니다. 당신의 선택에 행운을 빕니다!

HTTPS - 무엇이고, 어디에 사용되며, 왜 필요한가요? 보안 문제는 World Wide Web을 포함하여 모든 곳에서 관련됩니다. 사이트 간(내부 사이트가 아닌) 간에 전송되는 개인 데이터의 양이 증가함에 따라 최후의 수단소셜 네트워크의 발전으로 인해 보안 및 개인 정보 보호 문제가 활발히 제기되기 시작했습니다.

HTTPS는 무엇을 의미하나요?

HTTPS란 무엇이며 어떻게 해독되나요? 약어를 사용하지 않을 경우 Secure라고 써야 합니다. 그리고 모든 기능을 이해하기 위해 각 단어를 살펴 보겠습니다. HyperText는 추가 확장이나 스크립트(텍스트, 이미지, 표)가 필요하지 않은 웹사이트의 구성 요소를 설명하는 데 사용됩니다. 전송 프로토콜(Transfer Protocol) - 전송을 시작하기 위한 신호 역할을 하는 것이 무엇인지, 데이터가 지정되는 방법 등을 정의하는 서로 다른 시스템 간의 표준입니다. 보안 - 데이터 전송은 SSL 프로토콜을 사용하여 암호화되므로 가로채기가 어려울 뿐만 아니라 받다 기밀 정보(차단은 전투의 절반에 불과합니다). 안전한 HTTPS 연결은 해독이 불가능하지만 암호화된 정보를 검색하는 것을 어렵게 만듭니다. 왜 그렇게 되는지에 대해서는 나중에 설명하겠습니다.

개발의 역사

처음에는 중요한 정보(카드 번호, 비밀번호)를 보호하기 위해 보안 HTTPS 연결이 독점적으로 사용되었습니다. 이 프로토콜은 처음에는 은행 웹사이트나 온라인 상점과 상호 작용할 때만 배포되었습니다. 따라서 이러한 서비스의 사용자만이 HTTPS에 대해 알고 있었습니다. 그런 다음 검색 엔진이 연결되기 시작했고 소셜 미디어, 그리고 다른 사이트도 이에 따랐습니다. 처음에는 로그인과 비밀번호만 암호화되었지만 이제는 서버와 컴퓨터 간에 전송되는 모든 정보를 암호화할 수 있습니다. 이제 사용자와의 데이터 교환이 시작되기 전에 먼저 HTTPS 연결이 설정되어야 하며, 그런 다음 정보가 포함된 데이터 패킷이 전송됩니다.

전송된 문서는 어떻게 암호화되나요?

연결되지 않은 네트워크 간에 전송되는 엄청난 양의 데이터를 암호화하는 방법은 무엇입니까? 메시지를 입력하면 이메일, 수신자에게 도달하기 전에 수십 개의 다른 인터넷 제공업체에서 읽을 수 있습니다. 그리고 사기꾼이 그들 사이 어딘가에 끼어들면 그도 마찬가지입니다. 이렇게 하려면 연결을 열면 됩니다. 일반적으로 일어나는 일은 다음과 같습니다.

그러나 HTTPS 프로토콜을 사용하면 상황이 달라집니다. 이는 모든 데이터가 특정 코드를 사용하여 암호화되며 해당 정보에 액세스할 수 있는 "코드 워드"만 알고 있다는 컴퓨터와 사이트 서버 간의 계약과 비교할 수 있습니다. 이 경우 정보의 흐름에 접근하는 사람은 열쇠가 없기 때문에 정보를 읽을 수 없습니다. 순전히 이론적으로는 내용을 숙지하는 것이 가능하지만, 데이터를 해독하는 과정은 매우 오랜 시간이 걸립니다(가장 강력한 컴퓨터에서는 수년 또는 수십 년이 걸립니다).

암호화 기능

프로토콜 사용의 특징은 각 사용자에 대해 자체 키가 있는 별도의 인증서가 생성된다는 것입니다. 각 사이트의 인증서는 사용자의 브라우저에 다운로드되며, 향후 데이터를 가로챌 가능성이 있는 유일한 방법은 해당 사이트를 처음 방문할 때 인증서 다운로드를 가로채는 것입니다. 키 길이는 40~256비트일 수 있습니다. 그러나 대부분의 최신 사이트는 128비트 길이의 키를 사용합니다. 하한선은 최근 수출 제한이 발효된 미국에서만 찾을 수 있습니다. 프로토콜의 또 다른 특징은 하나의 인터넷 주소가 이 프로토콜에 의해 보호되는 하나의 사이트만 호스팅할 수 있다는 것입니다. 여러 사이트를 배열하는 것이 가능하지만 추가 확장을 사용해야 합니다.

결론

이것으로 HTTPS 프로토콜에 대한 기사가 끝났습니다. 당신은 그것이 무엇인지, 어디에 사용되는지 알고 있습니다. 당신의 것이 무엇보다도 당신의 손에 있다는 것을 기억하십시오. 따라서 HTTPS가 빨간색으로 강조 표시되면 잠시 기다리십시오. 사용자와 서버 사이에 데이터 손실을 허용하는 일종의 간격이 있을 가능성이 높습니다. 결국 데이터 도난 문제를 예방하려면 HTTPS를 정확하게 사용해야 하고, 프로토콜에서 문제가 보고되면 무시할 수 없습니다. 날짜가 잘못 설정된 등 부정확한 부분이 있는지 컴퓨터를 확인하는 것이 나쁠 것은 없습니다.

이 상황을 상상해 봅시다. 외부 서버에 웹사이트가 있습니다. 당신은 관리자로서 이를 실행합니다. 특정 행동, 특정 사용자 이름과 비밀번호를 사용하여 연결합니다. 두 번째 상황. 귀하는 웹머니 시스템 또는 이와 유사한 시스템의 사용자입니다. 지갑으로 작업을 수행하려면 시스템에 연결해야 합니다. 그러한 연결 중에 어떤 일이 일어날 수 있습니까? 누군가가 귀하의 컴퓨터와 서버 사이에 끼어들면, 그 사람은 귀하와 귀하가 전송한 데이터를 가로채고(스니핑), 그 데이터에서 귀하의 서버나 지갑에 접근할 수 있는 정보를 추출하고 귀하에게 해를 끼칠 수 있는 작업을 수행할 수 있습니다.

해야 할 일과 위험으로부터 자신을 보호하는 방법 비슷한 상황? 한 가지 옵션은 보안 프로토콜을 사용하여 작업하는 것입니다. 보안 프로토콜이 작동합니다. 다양한 레벨그리고 사용 다른 알고리즘암호화. 클라이언트와 서버는 네트워크의 메시지 흐름을 보는 제3자가 클라이언트와 서버 간에 어떤 정보가 교환되고 있는지 알 수 없는 방식으로 상호 작용합니다. 특수 인증서를 사용한 인증을 통해 데이터가 변경되거나 변조되지 않았는지 확인할 수 있습니다.

보안 연결을 생성하기 위해 여러 프로토콜이 개발되었습니다.

인터넷상의 보안 통신은 다음과 같은 다양한 프로토콜을 사용하여 구현될 수 있습니다. SSL(보안 소켓 계층), SHTTP(보안 HTTP) 및 PCT(개인 통신 기술). 이는 웹 서버와 브라우저 간의 통신 채널 보안을 보장하고 브라우저 또는 서버를 식별합니다. 보안 프로토콜에는 여러 가지 구현이 있지만 대부분의 웹 브라우저가 시스템에서 작동하려면 오늘날 가장 일반적인 프로토콜인 SSL 프로토콜을 계속 지원해야 합니다. 약어는 종종 그것을 지정하고 다른 것과 구별하기 위해 사용됩니다. HTTPS. 바로 이 라틴 문자"s"는 HTTP 프로토콜을 통해 인터넷에서 일반적이고 보안되지 않은 데이터 전송 채널을 기밀 또는 보안 채널로 전환합니다.

SSL 프로토콜은 1994년 Netscape Communications Corporation에 의해 도입되었습니다. 그런 다음 전송 프로토콜 계층(예: TCP) 위에 채널 보안이 제공되는 두 번째 버전이 제시되었습니다. 응용 프로그램 SSL을 통해 작업했습니다. SSL 프로토콜은 메시지를 암호화하고 서버 측 및 선택적으로 클라이언트 측에서 메시지 무결성 검사 및 인증을 통해 데이터 보호를 제공합니다. 2년 후, 암호화 알고리즘과 키 교환에 대한 지원을 확장한 이 프로토콜의 세 번째 버전이 출시되었습니다.

SSL 프로토콜은 세 가지 주요 속성이 있는 "보안 채널"을 제공합니다.

통신 보안. 초기 핸드셰이크 후에 암호화가 적용되고 비밀 키가 결정됩니다. 대칭 암호화 도구는 데이터를 암호화하는 데 사용됩니다(예: DES, RC4 등).
통신 세션의 참가자는 공유 키, 즉 비대칭 암호화(예: RSA, DSS 등)를 사용하여 식별할 수도 있습니다.
의사소통의 신뢰성. 차량암호화된 무결성 코드(MAC)를 사용하여 메시지의 무결성을 확인합니다. 보안 해시 함수(예: 보안 해시 알고리즘(SHA), MD5 등)는 MAC 코드를 계산하는 데 사용됩니다.

SSL 프로토콜의 목적은 안전하고 안정적인 통신을 보장하는 것입니다.

SSL 프로토콜의 주요 목적은 연결된 두 응용 프로그램 간에 안전하고 안정적인 통신을 제공하는 것입니다. 이 프로토콜은 두 개의 레이어로 구성됩니다. 전송 프로토콜(예: TCP) 위에 있는 가장 낮은 계층을 호출합니다. SSL 레코드 프로토콜. SSL Record Protocol은 다양한 프로토콜을 내장하는데 사용됩니다. 높은 수준그리고 제공한다 기본 세트 SSL 연결을 위한 두 가지 서비스인 기밀성과 메시지 무결성에 대한 보안 기능 및 지원을 제공합니다. 이러한 내장 프로토콜 중 하나는 SSL 핸드셰이크 프로토콜를 사용하면 애플리케이션 프로토콜이 데이터의 첫 번째 비트를 교환하기 전에 서버와 클라이언트가 서로를 식별하고 암호화 알고리즘과 암호화 키에 동의할 수 있습니다. SSL의 장점 중 하나는 애플리케이션 프로토콜에 독립적이라는 것입니다. 상위 수준 프로토콜은 SSL 프로토콜 위에 완전히 투명하게 계층화될 수 있습니다.

SSL의 또 다른 중요한 장점은 완전한 소프트웨어 플랫폼 독립성입니다. 프로토콜은 이식성의 원칙에 따라 개발되었으며 프로토콜 구성의 이념은 사용되는 응용 프로그램에 의존하지 않습니다.

SSL 프로토콜은 여러 계층으로 구성됩니다. 각 수준에서 메시지에는 길이, 설명 및 내용을 나타내는 여러 필드가 있습니다. SSL은 전송할 데이터를 가져와서 관리 가능한 블록으로 나누고, 필요한 경우 데이터를 압축하고, MAC 코드를 사용하고, 암호화를 수행하고, 결과를 전송합니다. 수신된 데이터는 해독, 검증, 압축 해제 및 재조립된 후 상위 클라이언트로 전송됩니다.

SSL 알고리즘은 공개 키 원칙을 기반으로 합니다. 이 원칙은 정보 인코딩/디코딩에 비대칭 키 쌍(공개 및 개인)을 사용하는 것을 기반으로 합니다. 공개 키는 모든 사람에게 배포됩니다. 그리고 그 도움으로 필요한 데이터가 암호화되며 다음을 통해서만 해독할 수 있습니다. 개인 키. 전송된 데이터의 보안은 궁극적으로 키 길이에 따라 달라집니다. 정보가 작으면 정보가 해킹될 수 있지만 상당한 컴퓨팅 성능이 필요합니다.

"인식" 프로세스는 여러 단계로 구성되어 있어 서버 속도가 느려집니다.

연결이 설정되면 클라이언트가 서버에 메시지를 보내는 것으로 초기화 프로세스가 시작됩니다. 클라이언트안녕하세요, 프로토콜 버전, 세션 식별자, 암호 제품군, 압축 방법 및 소스 난수를 포함합니다. 그런 다음 클라이언트는 서버로부터 메시지를 기다립니다. 서버안녕하세요 ClientHello 메시지와 동일한 매개변수를 포함하는 자격증, 서명된 서버의 공개 ECDH 키를 전송합니다. 디지털 서명 ECDSA 알고리즘에 따르면. 필요한 경우 메시지를 보낼 수 있습니다. 서버키교환(서버 키 교환) 및 인증서요청(인증서 요청). ServerDone 메시지를 통해 서버는 hello 단계가 끝났음을 알립니다. 서버가 인증된 후 클라이언트는 비밀 키를 계산합니다. 서버가 인증서를 요청하면 클라이언트는 메시지를 보냅니다. 자격증또는 통지 인증서 없음, 적절한 인증서를 사용할 수 없는 경우. 그런 다음 그는 자신의 공개 키를 메시지로 보냅니다. 클라이언트키교환. 결론적으로 이 단계클라이언트는 메시지를 보낼 수 있습니다 인증서확인클라이언트 인증서를 직접 확인하는 수단을 제공합니다.

그 후 일련의 중간 교환 작업이 수행되며, 그 동안 선택된 암호화 알고리즘, 키 및 비밀이 확정되고 서버는 클라이언트에게 최종 메시지를 보냅니다. 서버는 사용자를 식별한 후에만 해당 URL(Uniform Resource Locator)에서 지정한 리소스에 대한 클라이언트 액세스 권한을 부여합니다. 클라이언트 인증서를 사용한 인증을 통해 서버는 개별 사용자를 식별하고 관리자가 정의한 액세스 권한을 부여할 수 있습니다. 따라서 Internet Information Server는 공개 키 인증서를 사용하여 보안 채널 세션에서 클라이언트 인증을 지원합니다.

보안 연결을 통해 브라우저에서 작업하려면 SSL 프로토콜을 지원하고 포트 443을 통해 인터넷에 액세스할 수 있어야 합니다. 정상 작동프로토콜을 사용하려면 다음 브라우저 중 하나를 사용해야 합니다.

인터넷 익스플로러 5.01 이상
오페라 5.0 이상
넷스케이프 내비게이터 4.6 이상

이에 따라 구성해야 합니다. 즉, SSL2 및 SSL3 프로토콜에 대한 지원이 활성화되어야 합니다.

사용된 SSL 프로토콜은 어디에서 볼 수 있나요? 확실히 많은 분들이 하나 또는 다른 시스템을 사용하고 있습니다. 전자화폐— Yandex.Money, 웹머니, 기타. 서버에 연결할 때 인증서를 확인한 후(인증서가 유효한 경우) 보안 연결이 설정됩니다. 서버 연결도 같은 방식으로 이루어집니다. 전자 교환, 중개 플랫폼 및 기타 다양한 서비스를 제공합니다.

질문이 생깁니다. 왜 이런가요? 좋은 방법전송 및 수신된 정보 보호가 모든 곳에서 사용되지 않습니까? 여기에는 몇 가지 이유가 있습니다. 그 중 하나는 더 작은 것입니다. 처리량통신 수립 시 요청 처리 시, 정보 처리(암호화/복호화) 시. 부하가 높으면 이 문제가 심각해질 수 있습니다. 두 번째 문제는 연결하려면 다양한 인증서가 필요하다는 것입니다. 다양한 인터넷 서비스. 이를 저장하는 것뿐만 아니라 컴퓨터에서도 보호해야 합니다. 그렇기 때문에 유사한 수단전송된 데이터 보호는 다음과 같은 경우에 가장 자주 사용됩니다. 상업 프로젝트, 전송된 정보가 공개되면 심각한 결과를 초래할 수 있습니다.