SSL은 실제로 어떻게 작동합니까?

SSL은 실제로 어떻게 작동합니까?

---

SSL은 어떻게 작동합니까?

인증서는 클라이언트 (또는 브라우저)와 서버 (또는 웹 서버)에 어디에 설치되어 있습니까?

브라우저에 URL을 입력하고 서버에서 페이지를 가져올 때 트러스트 / 암호화 / 인증 프로세스는 어떻게 시작됩니까?

HTTPS 프로토콜은 인증서를 어떻게 인식합니까? 모든 트러스트 / 암호화 / 인증이 수행되는 인증서 인 경우 HTTP가 인증서와 작동하지 않는 이유는 무엇입니까?

---

참고 : 나는 원래의 답변을 매우 성급하게 작성했지만 그 이후로 상당히 인기있는 질문 / 답변으로 바뀌 었으므로 조금 확장하고 더 정확하게 만들었습니다.

TLS 기능

"SSL"은이 프로토콜을 나타내는 데 가장 많이 사용되는 이름이지만 SSL은 특히 90 년대 중반 Netscape가 설계 한 독점 프로토콜을 나타냅니다. "TLS"는 SSL을 기반으로하는 IETF 표준이므로 TLS를 사용하겠습니다. 요즘 웹의 거의 모든 보안 연결이 실제로 SSL이 아닌 TLS를 사용하고있을 가능성이 높습니다.

TLS에는 몇 가지 기능이 있습니다.

1. 응용 프로그램 계층 데이터를 암호화하십시오. (귀하의 경우 응용 프로그램 계층 프로토콜은 HTTP입니다.)
2. 서버를 클라이언트로 인증하십시오.
3. 클라이언트를 서버에 인증하십시오.

# 1과 # 2는 매우 일반적입니다. # 3은 덜 일반적입니다. 당신은 # 2에 집중하고있는 것 같습니다. 그래서 그 부분을 설명하겠습니다.

입증

서버는 인증서를 사용하여 클라이언트에 자신을 인증합니다. 인증서는 웹 사이트에 대한 정보를 포함하는 데이터 블랍 [1]입니다.

• 도메인 이름
• 공개 키
• 그것을 소유 한 회사
• 발행되었을 때
• 만료되면
• 누가 발행
• 기타.

인증서에 포함 된 공개 키를 사용하여 해당 개인 키로 만 해독 할 수있는 메시지를 암호화하여 해당 서버에 안전하게 저장해야 기밀성을 확보 할 수 있습니다. [2] 이 키 페어 KP1을 호출하여 나중에 혼동하지 않도록합시다. 인증서의 도메인 이름이 방문하는 사이트 (위의 2 번)와 일치하는지 확인할 수도 있습니다.

그러나 공격자가 서버와주고받는 패킷을 수정할 수 있다면, 공격자가 제시 한 인증서를 수정하고 자신의 공개 키를 삽입했거나 다른 중요한 세부 정보를 변경 한 경우 어떻게해야합니까? 이 경우 공격자는 안전하게 암호화되었다고 생각되는 모든 메시지를 가로 채서 수정할 수 있습니다.

이러한 공격을 막기 위해 인증서는 해당 공개 키를 가진 사람이 서명을 확인할 수있는 방식으로 다른 사람의 개인 키로 암호화되어 서명됩니다. 이 키 페어 KP2를 호출하여 서버와 동일한 키가 아님을 분명히하자.

인증 기관

누가 KP2를 만들었습니까? 인증서에 누가 서명 했습니까?

인증 기관 이 조금 단순화하면 KP2가 생성되며 개인 키를 사용하여 다른 조직의 인증서에 서명하는 서비스를 판매합니다. 예를 들어 인증서를 만들고 Verisign과 같은 회사에 개인 키로 서명하도록 비용을 지불합니다. [3] Verisign 외에 아무도이 개인 키에 액세스 할 수 없으므로이 서명을 위조 할 수 없습니다.

그리고 그 서명을 확인하기 위해 KP2의 공개 키를 어떻게 개인적으로 얻을 수 있습니까?

우리는 이미 인증서가 공개 키를 보유 할 수 있고 컴퓨터 과학자들은 재귀를 좋아한다는 것을 이미 알고 있습니다. 그렇다면 KP2 공개 키를 인증서에 넣어서 배포하는 것은 어떻습니까? 처음에는 약간 미친 소리로 들리지만 실제로는 정확히 작동합니다. Verisign 예제를 계속하여 Verisign은 자신이 누구인지, 서명 할 수있는 항목 유형 (기타 인증서) 및 공개 키에 대한 정보를 포함하는 인증서를 생성합니다.

이제 해당 Verisign 인증서 사본이 있으면이를 사용하여 방문하려는 웹 사이트의 서버 인증서에서 서명의 유효성을 검사 할 수 있습니다. 쉬운가요?!

글쎄, 그렇게 빨리. 나는 어딘가 에서 Verisign 인증서를 얻어야했다 . 누군가가 Verisign 인증서를 스푸핑하고 자체 공개 키를 거기에 넣으면 어떻게됩니까? 그런 다음 서버 인증서에서 서명을 위조 할 수 있으며, 우리가 시작했던 바로 중간자 (man-in-the-middle) 공격입니다.

인증서 체인

재귀 적으로 계속 생각하면서 우리는 물론 세 번째 인증서와 세 번째 키 페어 (KP3)를 소개하고이를 사용하여 Verisign 인증서에 서명 할 수 있습니다. 이를 인증서 체인이라고합니다. 체인의 각 인증서는 다음 인증서를 확인하는 데 사용됩니다. 이 재귀 접근 방식이 거북 / 인증서라는 것을 이미 알 수 있기를 바랍니다. 어디서 멈춰요?

우리는 무한한 수의 인증서를 만들 수 없기 때문에 인증서 체인은 분명히 어딘가 에서 중지 해야하며 자체 서명 된 체인에 인증서를 포함시켜 수행됩니다 .

나는 당신이 당신의 머리 폭발에서 뇌 물질 조각을 집어 들으면 잠시 잠시 멈출 것입니다. 자기 서명?!

예, 인증서 체인의 끝 부분 ( "루트")에는 자체 키 쌍을 사용하여 자체 서명하는 인증서가 있습니다. 이렇게하면 무한 재귀 문제가 제거되지만 인증 문제는 해결되지 않습니다. 정치, 이론 물리학을 전공하고 엉덩이를 걷어차는 것을 삼중이라고 말하고 맨 아래에 자신의 이름을 서명하는 가짜 프린스턴 졸업장을 만들 수있는 것처럼 누구나 자체 서명 된 인증서를 만들 수 있습니다.

이 문제에 대한 [흥미로운] 해결책은 명시 적으로 신뢰하는 자체 서명 된 인증서 세트를 선택하는 것입니다. 예를 들어 " 이 Verisign 자체 서명 인증서를 신뢰 합니다." 라고 말할 수 있습니다 .

With that explicit trust in place, now I can validate the entire certificate chain. No matter how many certificates there are in the chain, I can validate each signature all the way down to the root. When I get to the root, I can check whether that root certificate is one that I explicitly trust. If so, then I can trust the entire chain.

Conferred Trust

Authentication in TLS uses a system of conferred trust. If I want to hire an auto mechanic, I may not trust any random mechanic that I find. But maybe my friend vouches for a particular mechanic. Since I trust my friend, then I can trust that mechanic.

When you buy a computer or download a browser, it comes with a few hundred root certificates that it explicitly trusts.[4] The companies that own and operate those certificates can confer that trust to other organizations by signing their certificates.

This is far from a perfect system. Some times a CA may issue a certificate erroneously. In those cases, the certificate may need to be revoked. Revocation is tricky since the issued certificate will always be cryptographically correct; an out-of-band protocol is necessary to find out which previously valid certificates have been revoked. In practice, some of these protocols aren't very secure, and many browsers don't check them anyway.

Sometimes an entire CA is compromised. For example, if you were to break into Verisign and steal their root signing key, then you could spoof any certificate in the world. Notice that this doesn't just affect Verisign customers: even if my certificate is signed by Thawte (a competitor to Verisign), that doesn't matter. My certificate can still be forged using the compromised signing key from Verisign.

This isn't just theoretical. It has happened in the wild. DigiNotar was famously hacked and subsequently went bankrupt. Comodo was also hacked, but inexplicably they remain in business to this day.

Even when CAs aren't directly compromised, there are other threats in this system. For example, a government use legal coercion to compel a CA to sign a forged certificate. Your employer may install their own CA certificate on your employee computer. In these various cases, traffic that you expect to be "secure" is actually completely visible/modifiable to the organization that controls that certificate.

Some replacements have been suggested, including Convergence, TACK, and DANE.

Endnotes

[1] TLS certificate data is formatted according to the X.509 standard. X.509 is based on ASN.1 ("Abstract Syntax Notation #1"), which means that it is not a binary data format. Therefore, X.509 must be encoded to a binary format. DER and PEM are the two most common encodings that I know of.

[2] In practice, the protocol actually switches over to a symmetric cipher, but that's a detail that's not relevant to your question.

[3] Presumable, the CA actually validates who you are before signing your certificate. If they didn't do that, then I could just create a certificate for google.com and ask a CA to sign it. With that certificiate, I could man-in-the-middle any "secure" connection to google.com. Therefore, the validation step is a very important factor in the operation of a CA. Unfortunately, it's not very clear how rigorous this validation process is at the hundreds of CAs around the world.

[4] See Mozilla's list of trusted CAs.

---

HTTPS is combination of HTTP and SSL(Secure Socket Layer) to provide encrypted communication between client (browser) and web server (application is hosted here).

Why is it needed?

HTTPS encrypts data that is transmitted from browser to server over the network. So, no one can sniff the data during transmission.

How HTTPS connection is established between browser and web server?

1. Browser tries to connect to the https://payment.com.
2. payment.com server sends a certificate to the browser. This certificate includes payment.com server's public key, and some evidence that this public key actually belongs to payment.com.
3. Browser verifies the certificate to confirm that it has the proper public key for payment.com.
4. Browser chooses a random new symmetric key K to use for its connection to payment.com server. It encrypts K under payment.com public key.
5. payment.com decrypts K using its private key. Now both browser and the payment server know K, but no one else does.
6. Anytime browser wants to send something to payment.com, it encrypts it under K; the payment.com server decrypts it upon receipt. Anytime the payment.com server wants to send something to your browser, it encrypts it under K.

This flow can be represented by the following diagram:

---

I have written a small blog post which discusses the process briefly. Please feel free to take a look.

SSL Handshake

A small snippet from the same is as follows:

"Client makes a request to the server over HTTPS. Server sends a copy of its SSL certificate + public key. After verifying the identity of the server with its local trusted CA store, client generates a secret session key, encrypts it using the server's public key and sends it. Server decrypts the secret session key using its private key and sends an acknowledgment to the client. Secure channel established."

---

Mehaase has explained it in details already. I will add my 2 cents to this series. I have many blogposts revolving around SSL handshake and certificates. While most of this revolves around IIS web server, the post is still relevant to SSL/TLS handshake in general. Here are few for your reference:

• SSL Handshake and IIS
• Client certificate Authentication in SSL Handshake

Do not treat CERTIFICATES & SSL as one topic. Treat them as 2 different topics and then try to see who they work in conjunction. This will help you answer the question.

Establishing trust between communicating parties via Certificate Store

SSL/TLS communication works solely on the basis of trust. Every computer (client/server) on the internet has a list of Root CA's and Intermediate CA's that it maintains. These are periodically updated. During SSL handshake this is used as a reference to establish trust. For exampe, during SSL handshake, when the client provides a certificate to the server. The server will try to cehck whether the CA who issued the cert is present in its list of CA's . When it cannot do this, it declares that it was unable to do the certificate chain verification. (This is a part of the answer. It also looks at AIA for this.) The client also does a similar verification for the server certificate which it receives in Server Hello. On Windows, you can see the certificate stores for client & Server via PowerShell. Execute the below from a PowerShell console.

PS Cert:> ls Location : CurrentUser StoreNames : {TrustedPublisher, ClientAuthIssuer, Root, UserDS...}

Location : LocalMachine StoreNames : {TrustedPublisher, ClientAuthIssuer, Remote Desktop, Root...}

Browsers like Firefox and Opera don't rely on underlying OS for certificate management. They maintain their own separate certificate stores.

The SSL handshake uses both Symmetric & Public Key Cryptography. Server Authentication happens by default. Client Authentication is optional and depends if the Server endpoint is configured to authenticate the client or not. Refer my blog post as I have explained this in detail.

Finally for this question

How does the HTTPS protocol recognize the certificate? Why can't HTTP work with certificates when it is the certificates which do all the trust/encryption/authentication work?

Certificates is simply a file whose format is defined by X.509 standard. It is a electronic document which proves the identity of a communicating party. HTTPS = HTTP + SSL is a protocol which defines the guidelines as to how 2 parties should communicate with each other.

MORE INFORMATION

• In order to understand certificates you will have to understand what certificates are and also read about Certificate Management. These is important.
• Once this is understood, then proceed with TLS/SSL handshake. You may refer the RFC's for this. But they are skeleton which define the guidelines. There are several blogposts including mine which explain this in detail.

If the above activity is done, then you will have a fair understanding of Certificates and SSL.

참고URL : https://stackoverflow.com/questions/470523/how-does-ssl-really-work