현재 위치: 조직 및 개인 기업가의 코드

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

HTTPS는 무엇을 의미하나요?

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

개발의 역사

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

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

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

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

암호화 기능

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

결론

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

HTTP

암호화를 지원하는 HTTPS.

HTTPS 사용

HTTPS가 안전한 이유
SSL/TLS

HTTPS 배포

HTTP

HTTP의 모든 편리성과 인기에도 불구하고 한 가지 단점이 있습니다. 공개 양식어떤 방식으로도 보호되지 않습니다. A지점에서 B지점으로 이동하는 과정에서 인터넷 상의 정보는 수십 개의 중간 노드를 거치는데, 그 중 적어도 하나가 공격자의 통제를 받게 되면 데이터를 가로챌 수 있다. 보호되지 않은 상태로 사용할 때도 같은 일이 발생할 수 있습니다. Wi-Fi 네트워크, 예를 들어 카페에서. 보안 연결을 설정하기 위해 암호화를 지원하는 HTTPS 프로토콜이 사용됩니다.

HTTPS 사용
예를 들어 전자 서비스와 같은 일부 서비스에서는 결제 시스템, 데이터 보안이 매우 중요하므로 HTTPS만 사용합니다. 이 프로토콜은 개인 데이터를 포함하여 개인 정보를 처리하는 다른 서비스에서도 자주 사용됩니다. 많은 Yandex 서비스는 HTTPS 프로토콜(Passport, Mail, Direct, Metrica, Taxi, Yandex.Money 및 모든 형식)을 통해서만 작동합니다. 피드백사용자의 개인정보를 처리합니다.

HTTPS가 안전한 이유
HTTPS의 데이터 보호는 전송된 정보를 암호화하는 암호화 프로토콜 SSL/TLS를 통해 보장됩니다. 본질적으로 이 프로토콜은 HTTP의 래퍼입니다. 이는 귀하의 데이터를 암호화하여 다른 사람이 액세스할 수 없도록 만듭니다. SSL/TLS 프로토콜은 서로 익숙하지 않은 두 네트워크 참가자가 보안되지 않은 채널을 통해 보안 연결을 설정할 수 있다는 점에서 좋습니다.

오늘이 매월 마지막 날이고 인터넷 요금을 지불해야 한다는 것을 기억한다고 가정해 보겠습니다. 제공업체의 웹사이트에서 찾을 수 있습니다. 필수 링크그리고 가다 개인 계정. 전송된 모든 정보를 비밀로 유지하고 싶을 수도 있으므로 암호화해야 합니다. 이는 비밀번호, 결제 금액 및 신용카드 번호입니다. 문제는 처음에 컴퓨터가 공개 채널, 즉 HTTP를 통해 공급자의 서버와 데이터를 교환했다는 것입니다. 채널이 지속적으로 모니터링되고 있다고 가정할 때 이러한 조건에서 HTTPS를 통해 어떻게 보안 연결을 설정할 수 있습니까? 간단한 수학적 트릭을 사용하면 이를 수행할 수 있습니다.

보안 연결 작동 방식

디지털 인증서가 필요한 이유는 무엇입니까?

상자로 돌아가서 비유를 잠그면, 디지털 인증서상자에 있는 대화 상대의 자물쇠가 그 사람의 것인지 확인할 수 있습니다. 이것은 위조할 수 없는 독특한 자물쇠입니다. 따라서 다른 사람이 당신을 속여 자물쇠가 달린 상자를 보내면 자물쇠가 다르기 때문에 쉽게 이해할 수 있습니다.

HTTPS 배포

일반적으로 인터넷에서 HTTPS와 신기술의 확산은 해당 기술을 사용할 인프라가 얼마나 빨리 나타나는지에 따라 크게 달라집니다. 예를 들어 인터넷 사용자의 절반이 HTTPS를 지원하지 않는 브라우저를 사용한다면 많은 사이트에서 HTTPS를 사용할 수 없을 것입니다. 이는 HTTPS로 완전히 전환한 은행의 웹사이트를 고객의 절반이 이용할 수 없다는 사실로 이어질 것입니다.

또한, 암호화된 정보까지 가로챌 수 있는 SSL/TLS 등 암호화 프로토콜에서 취약점이 수시로 발견됩니다. 이러한 취약점을 제거하기 위해 프로토콜은 정기적으로 업데이트되며 각 후속 버전은 일반적으로 이전 버전보다 더 안정적입니다. 그러므로 보다 더 많은 사람최신 버전의 브라우저 및 기타 설치 중요한 프로그램, 더 안정적으로 보호됩니다.

암호화는 또 어디에 사용되나요?
인터넷에는 HTTP와 HTTPS 외에도 많은 데이터 교환 프로토콜이 있으며 보안도 제공해야 합니다. 예를 들어 Yandex.Mail은 주고받는 편지의 암호화를 지원합니다. 이에 대한 내용은 Habrahabr의 기술 블로그에서 읽을 수 있습니다. 우리는 사용자의 안전을 중요하게 생각하며 가능한 한 사용자의 데이터를 보호하려고 노력합니다.

","contentType":"text/html","amp":"

인터넷상의 모든 활동은 데이터 교환입니다. 동영상을 재생할 때마다 메시지를 보내세요. 소셜 네트워크또는 즐겨찾는 웹사이트를 열면 컴퓨터가 원하는 서버에 요청을 보내고 응답을 받습니다. 일반적으로 데이터 교환은 HTTP 프로토콜을 통해 발생합니다. 이 프로토콜은 정보 교환 규칙을 설정할 뿐만 아니라 데이터 전송을 위한 전송 역할도 합니다. 이 프로토콜의 도움으로 브라우저는 사이트 콘텐츠를 컴퓨터나 스마트폰에 다운로드합니다.

HTTP의 모든 편리함과 인기에도 불구하고 한 가지 단점이 있습니다. 데이터가 일반 텍스트로 전송되고 어떤 방식으로도 보호되지 않는다는 것입니다. A지점에서 B지점으로 이동하는 과정에서 인터넷 상의 정보는 수십 개의 중간 노드를 거치는데, 그 중 적어도 한 노드가 공격자의 통제를 받게 되면 데이터를 가로챌 수 있다. 예를 들어 카페에서 보안되지 않은 Wi-Fi 네트워크를 사용할 때도 동일한 일이 발생할 수 있습니다. 보안 연결을 설정하기 위해 암호화를 지원하는 HTTPS 프로토콜이 사용됩니다.

HTTPS 사용
예를 들어 전자 결제 시스템과 같은 일부 서비스에서는 데이터 보호가 매우 중요하므로 HTTPS만 사용합니다. 이 프로토콜은 개인 데이터를 포함하여 개인 정보를 처리하는 다른 서비스에서도 자주 사용됩니다. 많은 Yandex 서비스는 Passport, Mail, Direct, Metrica, Taxi, Yandex.Money 및 사용자의 개인 데이터를 처리하는 모든 형태의 피드백 등 HTTPS 프로토콜을 통해서만 작동합니다.

모든 최신 브라우저는 HTTPS 프로토콜을 지원합니다. 특별히 구성할 필요는 없으며 필요하고 가능할 때 프로세스에 자동으로 포함됩니다.

오늘이 매월 마지막 날이고 인터넷 요금을 지불해야 한다는 것을 기억한다고 가정해 보겠습니다. 공급자의 웹사이트에서 원하는 링크를 찾아 개인 계정으로 이동합니다. 전송된 모든 정보를 비밀로 유지하고 싶을 수도 있으므로 암호화해야 합니다. 이는 비밀번호, 결제 금액 및 신용카드 번호입니다. 문제는 처음에 컴퓨터가 공개 채널, 즉 HTTP를 통해 공급자의 서버와 데이터를 교환했다는 것입니다. 채널이 지속적으로 모니터링되고 있다고 가정할 때 이러한 조건에서 HTTPS를 통해 어떻게 보안 연결을 설정할 수 있습니까? 간단한 수학적 트릭을 사용하면 이를 수행할 수 있습니다.

보안 연결 작동 방식
당신이 다른 사람에게 무엇인가를 주고 싶다고 상상해 보십시오. 상자에 넣어서 우편으로 보내시면 됩니다. 그리고 택배기사나 다른 사람이 그것을 훔치는 것을 방지하기 위해 상자를 잠급니다. 택배기사가 상자를 배달했지만 수령인이 상자를 열 수 없습니다. 수령인에게는 열쇠가 없습니다. 그런 다음 그는 상자에 자물쇠를 걸어 당신에게 다시 보냅니다. 두 개의 자물쇠가 달린 상자를 받고 자물쇠를 제거한 후 다시 보내세요. 이제 안전합니다. 수취인은 마침내 자신의 자물쇠만 걸려 있는 상자를 받고 그것을 열고 당신이 보낸 것을 꺼냅니다.

이는 대화 상대와 암호화된 메시지를 교환하는 데 필요했습니다. 상자 안에 당신은 그에게 암호화 키를 보냈고 이제 그것은 두 사람 모두에게 알려졌습니다. 이제 암호화된 메시지를 누군가 가로챌 염려 없이 공개적으로 교환할 수 있습니다. 하지만 키가 없으면 메시지를 이해할 수 없습니다. 왜 그렇게 복잡하며, 소포와 자물쇠 열쇠를 별도로 전달할 수 없는 이유는 무엇입니까? 물론 가능했지만 이 경우 키를 가로채지 않고 다른 사람이 패키지를 열지 않는다는 보장도 없습니다.

SSL/TLS 프로토콜의 작동은 유사한 원칙을 기반으로 합니다. HTTPS를 통해 보안 연결을 설정할 때 컴퓨터와 서버는 먼저 공유 비밀 키를 선택한 다음 해당 키를 사용하여 암호화하여 정보를 교환합니다. 공유 비밀 키는 각 통신 세션마다 다시 생성됩니다. 가로챌 수 없으며 추측하기가 거의 불가능합니다. 일반적으로 100자를 초과하는 숫자입니다. 이 일회성 비밀 키는 브라우저와 서버 간의 모든 통신을 암호화하는 데 사용됩니다. 이상적인 시스템은 다음을 보장하는 것 같습니다. 절대적인 안전사이. 그러나 완전히 신뢰할 수 있으려면 대화 상대가 자신이 말하는 사람이 누구인지 보장하는 것이 부족합니다.

디지털 인증서가 필요한 이유는 무엇입니까?
귀하의 패키지가 수신자에게 도착하지 못했다고 상상해보십시오. 다른 사람이 패키지를 가로 채었습니다. 이 사람은 자신의 자물쇠를 달고 보낸 사람의 주소를 위조하여 당신에게 보냅니다. 따라서 그가 암호의 비밀 키를 알게 되면, 그는 귀하를 대신하여 귀하의 실제 수취인에게 이를 전달합니다. 결과적으로 귀하와 대화 상대는 암호화 키가 안전하게 전송되었으며 암호화된 메시지를 교환하는 데 사용될 수 있음을 확신합니다. 그러나 이러한 모든 메시지는 귀하가 그 존재를 짐작할 수 없는 제3자가 쉽게 읽고 가로챌 수 있습니다. 별로 안전하지 않습니다.

같은 방식으로 제3자가 인터넷상의 두 장치 사이의 연결에 조용히 끼어들어 모든 메시지를 해독할 수 있습니다. 예를 들어, 보안 연결을 통해 인터넷 비용을 지불했고 지불금이 수령되었습니다. 하지만 공격자는 귀하의 신용 카드 번호와 인증 코드를 가로 채었습니다. 당신은 아직 그것에 대해 모르고 있고, 알게 되면 너무 늦을 것입니다. 디지털 인증서는 이러한 상황을 방지하는 데 도움이 됩니다. 전자문서, 서버를 식별하는 데 사용됩니다.

사용자에게는 인증서가 필요하지 않지만 보안 연결을 설정하려는 모든 서버(사이트)에는 인증서가 있어야 합니다. 인증서는 1) 발급받은 사람이 실제로 존재한다는 것과 2) 인증서에 기재된 서버를 통제하고 있다는 두 가지를 증명합니다. 인증 기관은 인증서 발급을 담당합니다. 여권 사무소. 여권과 마찬가지로 인증서에는 이름(또는 조직 이름)과 인증서의 진위를 증명하는 서명을 포함하여 소유자에 대한 정보가 포함되어 있습니다. 브라우저가 보안 HTTPS 연결을 설정할 때 가장 먼저 수행하는 작업은 인증서의 진위 여부를 확인하는 것입니다. 확인이 성공한 경우에만 데이터 교환이 시작됩니다.

상자와 자물쇠에 대한 비유로 돌아가면 디지털 인증서를 통해 대화 상대의 상자에 있는 자물쇠가 그 사람의 것인지 확인할 수 있습니다. 이것은 위조할 수 없는 독특한 자물쇠입니다. 따라서 다른 사람이 당신을 속여 자물쇠가 달린 상자를 보내면 자물쇠가 다르기 때문에 쉽게 이해할 수 있습니다.

HTTPS 배포
모든 인터넷 서비스에서 가장 인기 있는 권장 사항 중 하나는 항상 다음을 사용하는 것입니다. 최신 버전 소프트웨어. 이것이 왜 필요한지 생각해 본 적이 없다면 보안 분야의 최신 개발을 지원하는 이유 중 하나가 여기에 있습니다.

또한, 암호화된 정보까지 가로챌 수 있는 SSL/TLS 등 암호화 프로토콜에서 취약점이 수시로 발견됩니다. 이러한 취약점을 제거하기 위해 프로토콜은 정기적으로 업데이트되며 각 후속 버전은 일반적으로 이전 버전보다 더 안정적입니다. 따라서 더 많은 사람들이 최신 버전의 브라우저와 기타 중요한 프로그램을 설치할수록 더욱 안정적으로 보호받을 수 있습니다.

","인스턴트아티클":"

인터넷상의 모든 활동은 데이터 교환입니다. 비디오를 재생하거나 소셜 네트워크에 메시지를 보내거나 즐겨찾는 웹사이트를 열 때마다 컴퓨터는 원하는 서버에 요청을 보내고 응답을 받습니다. 일반적으로 데이터 교환은 HTTP 프로토콜을 통해 발생합니다. 이 프로토콜은 정보 교환 규칙을 설정할 뿐만 아니라 데이터 전송을 위한 전송 역할도 합니다. 이 프로토콜의 도움으로 브라우저는 사이트 콘텐츠를 컴퓨터나 스마트폰에 다운로드합니다.

모든 최신 브라우저는 HTTPS 프로토콜을 지원합니다. 특별히 구성할 필요는 없으며 필요하고 가능할 때 프로세스에 자동으로 포함됩니다.

SSL/TLS 프로토콜의 작동은 유사한 원칙을 기반으로 합니다. HTTPS를 통해 보안 연결을 설정할 때 컴퓨터와 서버는 먼저 공유 비밀 키를 선택한 다음 해당 키를 사용하여 암호화하여 정보를 교환합니다. 공유 비밀 키는 각 통신 세션마다 다시 생성됩니다. 가로챌 수 없으며 추측하기가 거의 불가능합니다. 일반적으로 100자를 초과하는 숫자입니다. 이 일회성 비밀 키는 브라우저와 서버 간의 모든 통신을 암호화하는 데 사용됩니다. 연결의 절대적인 보안을 보장하는 이상적인 시스템처럼 보입니다. 그러나 완전히 신뢰할 수 있으려면 대화 상대가 자신이 말하는 사람이 누구인지 보장하는 것이 부족합니다.

같은 방식으로 제3자가 인터넷상의 두 장치 사이의 연결에 조용히 끼어들어 모든 메시지를 해독할 수 있습니다. 예를 들어, 보안 연결을 통해 인터넷 비용을 지불했고 지불금이 수령되었습니다. 하지만 공격자는 귀하의 신용 카드 번호와 인증 코드를 가로 채었습니다. 당신은 아직 그것에 대해 모르고 있고, 알게 되면 너무 늦을 것입니다. 서버를 식별하는 데 사용되는 전자 문서인 디지털 인증서는 이러한 상황을 방지하는 데 도움이 됩니다.

사용자에게는 인증서가 필요하지 않지만 보안 연결을 설정하려는 모든 서버(사이트)에는 인증서가 있어야 합니다. 인증서는 1) 발급받은 사람이 실제로 존재한다는 것과 2) 인증서에 기재된 서버를 통제하고 있다는 두 가지를 증명합니다. 인증서는 여권 사무소와 같은 인증 센터에서 발급됩니다. 여권과 마찬가지로 인증서에는 이름(또는 조직 이름)과 인증서의 진위를 증명하는 서명을 포함하여 소유자에 대한 정보가 포함되어 있습니다. 인증서의 신뢰성을 확인하는 것은 보안 HTTPS 연결을 설정할 때 브라우저가 가장 먼저 수행하는 작업입니다. 확인이 성공한 경우에만 데이터 교환이 시작됩니다.

HTTPS 배포
모든 인터넷 서비스에서 가장 인기 있는 권장 사항 중 하나는 항상 최신 버전의 소프트웨어를 사용하는 것입니다. 이것이 왜 필요한지 생각해 본 적이 없다면 보안 분야의 최신 개발을 지원하는 이유 중 하나가 여기에 있습니다.

"),,"proposedBody":("출처":"

모든 최신 브라우저는 HTTPS 프로토콜을 지원합니다. 특별히 구성할 필요는 없으며 필요하고 가능할 때 프로세스에 자동으로 포함됩니다.

이는 대담자와 암호화된 메시지를 교환하는 데 필요했습니다. 상자 안에 당신은 그에게 암호화 키를 보냈고 이제 그것은 두 사람 모두에게 알려졌습니다. 이제 암호화된 메시지를 누군가 가로챌 염려 없이 공개적으로 교환할 수 있습니다. 하지만 키가 없으면 메시지를 이해할 수 없습니다. 왜 그렇게 복잡하며, 소포와 자물쇠 열쇠를 별도로 전달할 수 없는 이유는 무엇입니까? 물론 가능했지만 이 경우 키를 가로채지 않고 다른 사람이 패키지를 열지 않는다는 보장도 없습니다.

SSL/TLS 프로토콜의 작동은 유사한 원칙을 기반으로 합니다. HTTPS를 통해 보안 연결을 설정할 때 컴퓨터와 서버는 먼저 공유 비밀 키를 선택한 다음 해당 키를 사용하여 암호화하여 정보를 교환합니다. 공유 비밀 키는 각 통신 세션마다 다시 생성됩니다. 가로챌 수 없으며 추측하기가 거의 불가능합니다. 일반적으로 100자를 초과하는 숫자입니다. 이 일회성 비밀 키는 브라우저와 서버 간의 모든 통신을 암호화하는 데 사용됩니다. 연결의 절대적인 보안을 보장하는 이상적인 시스템처럼 보입니다. 그러나 완전히 신뢰할 수 있으려면 대화 상대가 자신이 말하는 사람이 누구인지 보장하는 것이 부족합니다.

같은 방식으로 제3자가 인터넷에 있는 두 장치 간의 연결을 조용히 중단하고 모든 메시지를 해독할 수 있습니다. 예를 들어, 보안 연결을 통해 인터넷 비용을 지불했고 지불금이 수령되었습니다. 하지만 공격자는 귀하의 신용 카드 번호와 인증 코드를 가로 채었습니다. 당신은 아직 그것에 대해 모르고 있고, 알게 되면 너무 늦을 것입니다. 서버를 식별하는 데 사용되는 전자 문서인 디지털 인증서는 이러한 상황을 방지하는 데 도움이 됩니다.

사용자에게는 인증서가 필요하지 않지만 보안 연결을 설정하려는 모든 서버(사이트)에는 인증서가 있어야 합니다. 인증서는 1) 발급받은 사람이 실제로 존재한다는 것과 2) 인증서에 기재된 서버를 통제하고 있다는 두 가지를 증명합니다. 인증서는 여권 사무소와 같은 인증 센터에서 발급됩니다. 여권과 마찬가지로 인증서에는 이름(또는 조직 이름)과 인증서의 진위를 증명하는 서명을 포함하여 소유자에 대한 정보가 포함되어 있습니다. 브라우저가 보안 HTTPS 연결을 설정할 때 가장 먼저 수행하는 작업은 인증서의 진위 여부를 확인하는 것입니다. 확인이 성공한 경우에만 데이터 교환이 시작됩니다.

모든 최신 브라우저는 HTTPS 프로토콜을 지원합니다. 특별히 구성할 필요는 없으며 필요하고 가능할 때 프로세스에 자동으로 포함됩니다.

SSL/TLS 프로토콜의 작동은 유사한 원칙을 기반으로 합니다. HTTPS를 통해 보안 연결을 설정할 때 컴퓨터와 서버는 먼저 공유 비밀 키를 선택한 다음 해당 키를 사용하여 암호화하여 정보를 교환합니다. 공유 비밀 키는 각 통신 세션마다 다시 생성됩니다. 가로챌 수 없으며 추측하기가 거의 불가능합니다. 일반적으로 100자를 초과하는 숫자입니다. 이 일회성 비밀 키는 브라우저와 서버 간의 모든 통신을 암호화하는 데 사용됩니다. 연결의 절대적인 보안을 보장하는 이상적인 시스템처럼 보입니다. 그러나 완전히 신뢰할 수 있으려면 대화 상대가 자신이 말하는 사람이 누구인지 보장하는 것이 부족합니다.

","contentType":"text/html"),"authorId":"5105614","slug":"77455","canEdit":false,"canComment":false,"isBanned":false,"canPublish" :false,"viewType":"old","isDraft":false,"isOnModeration":false,"isSubscriber":false,"commentsCount":247,"modificationDate":"2017년 10월 30일 월요일 15:24:00 GMT +0000(UTC)","isAutoPreview":false,"showPreview":true,"approvedPreview":("source":"

","contentType":"text/html"),"proposedPreview":("source":"

인터넷상의 모든 활동은 데이터 교환입니다. 비디오를 재생하거나 소셜 네트워크에 메시지를 보내거나 즐겨찾는 웹사이트를 열 때마다 컴퓨터는 원하는 서버에 요청을 보내고 응답을 받습니다. 일반적으로 데이터 교환은 HTTP 프로토콜을 통해 이루어집니다. 이 프로토콜은 정보 교환 규칙을 설정할 뿐만 아니라 데이터 전송을 위한 전송 역할도 합니다. 이 프로토콜의 도움으로 브라우저는 사이트 콘텐츠를 컴퓨터나 스마트폰에 다운로드합니다.

","contentType":"text/html"),"titleImage":null,"tags":[("displayName":"security","slug":"bezopasnost","categoryId":"1810032"," url":"/blog/company??tag=bezopasnost")],"isModerator":false,"isTypography":false,"metaDescription":"","metaKeywords":"","관련Title":"", "isAutoRelated":false,"commentsEnabled":true,"url":"/blog/company/77455","urlTemplate":"/blog/company/%slug%","fullBlogUrl":"https://yandex .ru/blog/company","addCommentUrl":"/blog/createComment/company/77455","updateCommentUrl":"/blog/updateComment/company/77455","addCommentWithCaptcha":"/blog/createWithCaptcha/company/ 77455","changeCaptchaUrl":"/blog/api/captcha/new","putImageUrl":"/blog/image/put","urlBlog":"/blog/company","urlEditPost":"/blog/ 5628844c7eba6ef16f804625/edit","urlSlug":"/blog/post/generateSlug","urlPublishPost":"/blog/5628844c7eba6ef16f804625/publish","urlUnpublishPost":"/blog/5628844c7eba6ef16f804625 /unp 게시","urlRemovePost":"/ blog/5628844c7eba6ef16f804625/removePost","urlDraft":"/blog/company/77455/draft","urlDraftTemplate":"/blog/company/%slug%/draft","urlRemoveDraft":"/blog/5628844c7eba6ef16f804625/remo ve 초안 ","urlTagSuggest":"/blog/api/suggest/company","urlAfterDelete":"/blog/company","isAuthor":false,"subscribeUrl":"/blog/api/subscribe/5628844c7eba6ef16f804625", " unsubscribeUrl":"/blog/api/unsubscribe/5628844c7eba6ef16f804625","urlEditPostPage":"/blog/company/5628844c7eba6ef16f804625/edit","urlForTranslate":"/blog/post/translate","urlRelateIssue":"/blog / post/updateIssue","urlUpdateTranslate":"/blog/post/updateTranslate","urlLoadTranslate":"/blog/post/loadTranslate","urlTranslationStatus":"/blog/company/77455/translationInfo","urlRelatedArticles" : "/blog/api/관련Articles/company/77455","author":("id":"5105614","uid":("value":"5105614","lite":false,"hosted": false ","별칭":("13":"kadaner"),"login":"minushuman","display_name":("name":"Alexey","avatar":("default":"21377/ 5105614 -16014116","비어 있음":false)),,"주소":" [이메일 보호됨]","defaultAvatar":"21377/5105614-16014116","imageSrc":"https://avatars.mds.yandex.net/get-yapic/21377/5105614-16014116/islands-middle","isYandexStaff": true),"originalModificationDate":"2017-10-30T12:24:18.831Z","socialImage":("orig":("fullPath":"https://avatars.mds.yandex.net/get-yablogs /49865/file_1465551301378/orig")))))">

HTTPS 프로토콜은 무엇이며 인터넷에서 사용자를 어떻게 보호합니까?

모든 최신 브라우저는 HTTPS 프로토콜을 지원합니다. 특별히 구성할 필요는 없으며 필요하고 가능할 때 프로세스에 자동으로 포함됩니다.

SSL/TLS 프로토콜의 작동은 유사한 원칙을 기반으로 합니다. HTTPS를 통해 보안 연결을 설정할 때 컴퓨터와 서버는 먼저 공유 비밀 키를 선택한 다음 해당 키를 사용하여 암호화하여 정보를 교환합니다. 공유 비밀 키는 각 통신 세션마다 다시 생성됩니다. 가로챌 수 없으며 추측하기가 거의 불가능합니다. 일반적으로 100자를 초과하는 숫자입니다. 이 일회성 비밀 키는 브라우저와 서버 간의 모든 통신을 암호화하는 데 사용됩니다. 연결의 절대적인 보안을 보장하는 이상적인 시스템처럼 보입니다. 그러나 완전히 신뢰할 수 있으려면 대화 상대가 자신이 말하는 사람이 누구인지 보장하는 것이 부족합니다.

HTTP는 이미 알고 있듯이 데이터 전송을 위한 애플리케이션 계층 프로토콜입니다. 이것이 바로 우리가 HTTP://를 입력한 다음 로 이동하는 이유입니다. 그러면 해당 주소를 통해 이 웹사이트의 HTTP 버전으로 이동하게 됩니다.

이제 보세요. 문자 그대로 서버로 텍스트가 전송되고 그 반대로 전송됩니다. 이는 다음과 같습니다. HTTP 프로토콜이 여기에 지정됩니다. 텍스트는 HTTP 프로토콜이 사용되었음을 나타냅니다. 날짜, 서버가 있습니다. 아래에는 HTML 코드가 표시됩니다. 이는 탐색하면 찾을 수 있는 코드입니다. 소스 코드웹 페이지. 이것이 그의 모습입니다. 따라서 HTTP는 일반 텍스트입니다. 이것을 닫고 Google로 이동하여 여기에서 HTTPS로 변경하겠습니다. 이제 TLS 또는 SSL을 통해 HTTP를 실행하고 있습니다. HTTPS는 데이터 암호화, 인증, 일반적으로 서버 측 메시지 무결성, 선택적으로 클라이언트 또는 브라우저 인증인 TLS를 사용하기 때문에 TLS 보안을 제공합니다.

HTTPS를 사용하여 웹사이트에 액세스하면 웹 서버는 SSL을 호출하고 통신을 보호하는 작업을 시작합니다. 서버는 보안 세션을 설정해야 함을 나타내는 메시지를 클라이언트에 다시 보내고 클라이언트는 보안 매개변수를 보내 응답합니다. 이는 클라이언트가 다음과 같이 말할 것임을 의미합니다. "나는 이러한 디지털 서명을 사용할 준비가 되었습니다. 이러한 키 교환 방법, 알고리즘을 사용할 준비가 되었습니다. 이러한 대칭 키를 사용할 준비가 되었습니다." 서버는 일치하는 항목이 발견될 때까지 이러한 보안 매개변수를 자체 매개변수와 비교하며, 이를 "핸드셰이크" 단계라고 합니다.

서버는 디지털 인증서를 보내 클라이언트를 인증합니다. 나중에 인증서를 살펴보고 클라이언트가 서버를 신뢰하기로 결정하면 프로세스가 계속됩니다. 서버는 상호 인증을 위해 클라이언트에게 디지털 인증서도 보내도록 요청할 수 있지만 이는 자주 발생하지 않습니다.

귀하와 상대방을 인증하는 완전히 안전한 엔드투엔드 세션이 필요한 경우 양쪽 당사자가 디지털 서명한 인증서를 사용해야 합니다. 디지털 인증서에 접근하면 이것이 어떻게 작동하는지 더 잘 이해할 수 있을 것입니다.

클라이언트는 예를 들어 AES 알고리즘을 사용하여 대칭 세션 키를 생성하고 서버의 공개 키를 사용하여 암호화합니다. 이 암호화된 키는 웹 서버로 전송되며 클라이언트와 서버 모두 이 대칭 키를 사용하여 서로 보내는 데이터를 암호화합니다.

이것이 안전한 데이터 교환 채널이 설정되는 방법입니다.

TLS가 작동하려면 TLS 지원 서버와 브라우저가 필요하며 Wikipedia 기사에서 본 것처럼 모든 최신 브라우저는 TLS를 지원합니다. 그리고 모든 브라우저에는 TLS가 사용되고 있음을 나타내는 HTTPS가 표시되며 자물쇠도 자주 표시됩니다. 모든 브라우저에는 HTTPS 또는 TLS와 함께 HTTP를 사용하는지 여부를 알 수 있도록 비슷한 기능이 있습니다.

여기 성을 보면 알 수 있어요 기술적인 세부사항어떤 암호화 알고리즘이 사용되는지. 안에 이 경우, TLS가 사용됩니다. Diffie-Hellman, RSA를 사용한 타원 곡선. 128비트 키를 갖춘 AES, GCM 암호화 모드 및 데이터 무결성을 위한 SHA256. 이 모든 것은 클라이언트와 서버 간에 협상됩니다.

그리고 Wireshark를 살펴보면 Wireshark는 프로토콜 분석기로서 트래픽이 어떻게 수신되고 전송되는지 확인할 수 있습니다. 여기서는 브라우저인 내 클라이언트가 "이것이 내가 지원하는 것입니다."라고 말하는 대화가 있는 것을 볼 수 있습니다. 그러자 서버가 대답했습니다. "글쎄요, 이것이 제가 실제로 사용하고 싶은 것입니다." 그런 다음 서버는 다음과 같은 인증서를 제공했습니다. 디지털 서명그리고 그에 대한 공개 키입니다.

살펴보아야 할 또 다른 사이트는 SSL Labs입니다. 여기에 사이트를 입력하거나 HTTPS를 통해 실행되는 사이트 URL을 입력하면 해당 사이트에서 어떤 암호화 옵션을 제공하는지 확인할 수 있습니다.

그리고 여기로 갈 수 있습니다. 이는 Firefox 주소 표시줄의 다양한 색상과 아이콘이 무엇을 의미하는지 알려줍니다. 그리고 이 모든 것은 특정 사이트에서 사용되는 보안 조치의 수준을 반영합니다. 우리 얘기 중이야기밀성, 인증 및 무결성에 대해.

여기 회색이 보입니다 지구, 이는 해당 웹사이트가 식별 정보를 지원하지 않음을 의미합니다. Firefox와 웹사이트 간의 연결은 암호화되지 않거나 부분적으로만 암호화되므로 도청으로부터 안전하다고 간주되어서는 안 됩니다.
그레이 캐슬:

이 웹사이트에는 암호화되지 않은 요소(예: 이미지)가 포함되어 있으므로 연결이 완전히 안전하지 않습니다.
주황색 경고 삼각형:

웹사이트는 식별 정보를 제공하지 않습니다.
Firefox와 웹사이트 간의 연결은 부분적으로만 암호화되어 도청을 방지하지 못합니다.
회색 경고 삼각형:

홈페이지 주소가 확인되었습니다.

Firefox와 웹사이트 간의 연결은 도청을 방지하기 위해 암호화됩니다.
그린 캐슬:
웹사이트 주소는 EV(Extended Validation) 인증서를 사용하여 확인되었습니다. 이는 웹사이트 소유자가 자신이 누구인지 증명하기 위해 훨씬 더 많은 정보, 훨씬 더 신뢰할 수 있는 정보를 제공해야 함을 의미합니다. 따라서 EV와 녹색 자물쇠가 보이면 사이트 소유자에 대한 광범위한 검증이 수행되었음을 의미합니다.
Firefox와 웹사이트 간의 연결은 도청을 방지하기 위해 암호화됩니다. 그런 것들.

웹사이트 개발,

알고리즘

번역

어쨌든 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 연결은 더 일찍 발생합니다. 단일 인증서서버에 있는 사이트를 요청할 때 전체 서버에 대한 정보가 사용됩니다.

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

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

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

인터넷상의 보안 통신은 다음과 같은 다양한 프로토콜을 사용하여 구현될 수 있습니다. SSL(보안 소켓 계층), 보안 HTTP(SHTTP) 및 개인 통신 기술(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 메시지와 동일한 매개변수를 포함하는 자격증는 ECDSA 알고리즘을 사용하여 디지털 서명된 서버의 공개 ECDH 키를 전송합니다. 필요한 경우 메시지를 보낼 수 있습니다. 서버키교환(서버 키 교환) 및 인증서요청(인증서 요청). ServerDone 메시지를 통해 서버는 hello 단계가 끝났음을 알립니다. 서버가 인증된 후 클라이언트는 비밀 키를 계산합니다. 서버가 인증서를 요청하면 클라이언트는 메시지를 보냅니다. 자격증또는 통지 인증서 없음, 적절한 인증서를 사용할 수 없는 경우. 그런 다음 그는 자신의 공개 키를 메시지로 보냅니다. 클라이언트키교환. 결론적으로 이 단계클라이언트는 메시지를 보낼 수 있습니다 인증서확인클라이언트 인증서를 직접 확인하는 수단을 제공합니다.

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

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

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

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

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

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