Geekly Articles each Day
📜 ⬆️ ⬇️

Trust Principle in HTTPS

Now, probably, more than half of the servers have moved from the http to the https protocol. What for? Well, it's supposedly cool, sekyurno.


What is this sekyurnost? A lot of articles have already been written on this topic, including on Habré. But I would like to add one more.


Why decided to write


I, in general, is an Android developer by specialty, and I do not really shy about cryptography and information security protocols. So when I had to deal with this directly, I was a little shocked by the size of the abyss in my theoretical knowledge.


I began to rummage in different sources, and it turned out that this topic is not so easy to understand, and it’s not enough just to read a couple of articles on Habré or Wiki, and I never met an absolutely exhaustive and understandable source to refer and say, this is the Bible. " Therefore, it took a lot of time for me to "understand a little". So, having figured it out, I decided to share it, and write an article for newbies like me, or just for people who are wondering why there is sometimes https rather than http in the URL bar.


What does a secure communication channel mean?


In order for a data channel to be considered secure, 3 basic principles must be followed:



In this article I would like to talk in detail only about the mechanism of Confidence.


What does Trust mean?


You can trust your interlocutor only if you know for sure that he is who he claims to be.
The simplest example - you know the interlocutor personally, more complex - you know someone who personally knows your intended interlocutor and this someone guarantees that the interlocutor can be trusted.


Life example


Imagine you want to buy an apartment.
To do this, you find a Realtor who sells apartments.
The realtor says that he works with a certain Developer , and offers an apartment from this Developer .
The developer says that the housing he builds will be handed over, and those who paid him the money to the Realtor will receive his ownership, and the legality of the construction and ownership will be secured by the State .
In total, we have 4 subjects you , Realtor , Developer , State .
To ensure that the transaction took place successfully and no one deceived anyone, the State created laws defining documents that guarantee the legality of transactions, and a printing or signature mechanism that guarantees the authenticity of these documents.


You have examples of these documents and seals, you can take them from the State .
You have the right to demand from the Realtor original construction documents.
The realtor takes the developer's documents, which are backed up with the documents of the State and makes sure that apartments can be sold - they are legal.
The developer , in turn, receives documents from the State .
Those. now you can safely conduct a dialogue only with the Realtor , based on his documents sealed by the Developer and the State !



HTTPS Trust


And now we will change the names of the characters from the Life Example.
You = Client (Client)
Realtor = Server (Server)
Developer = Intermediate Certification Authority (Intermediate CA)
State = Main Certification Authority (Root CA)



The main Certification Authority (Root Certificate Authority, CA) is a generally recognized well-known company, which international organizations have given authority to manage certificates and signatures, in short, this company is trusted by everyone.


It may give some authority to Intermediate Certification Authorities (Intermediate CA) , and they will sign documents on behalf of the Main Center .


Let's go to the math


The words were mentioned: signature, certificate, etc. How to implement it? Asymmetric encryption comes to the rescue.


In order not to go into details and not to explain discrete mathematics and cryptography, let's clarify a couple of things:


1) In short, and the main thing about asymmetric encryption.
There are 2 keys - Public and Private Key . Actually, keys are just big numbers.
If a message is encrypted with Public , then only the corresponding Private Key can decrypt it.
And vice versa:
If the message is encrypted by Private , then it can only be decrypted by the corresponding Public Key .
The private key is not given to anyone, the Public key is actually public.


2) Digital Signature is a part of the document encrypted with the Subscriber’s Private Key . If it can be decrypted with the Public Key of the Subscriber, then we can confidently assert that it was the Subscriber who encrypted it.


3) A Certificate (Digital Certificate) is usually a file, most often with the extension .cer or .pem.
It contains:



Certificate Example

COMODO Certification Authority
Identity: COMODO Certification Authority
Verified by: COMODO Certification Authority
Expires: 12/31/29


Subject Name
C (Country): GB
ST (State): Greater Manchester
L (Locality): Salford
O (Organization): COMODO CA Limited
CN (Common Name): COMODO Certification Authority


Issuer Name
C (Country): GB
ST (State): Greater Manchester
L (Locality): Salford
O (Organization): COMODO CA Limited
CN (Common Name): COMODO Certification Authority


Issued Certificate
Version: 3
Serial Number: 4E 81 2D 8A 82 65 E0 0B 02 EE 3E 35 02 46 E5 3D
Not Valid Before: 2006-12-01
Not Valid After: 2029-12-31


Certificate Fingerprints
SHA1: 66 31 BF 9E F7 4F 9E B6 C9 D5 A6 0C BA 6A BE D1 F7 BD EF 7B
MD5: 5C 48 DC F7 42 72 EC 56 94 6D 1C CC 71 35 80 75


Public Key Info
Key Algorithm: RSA
Key Parameters: 05 00
Key Size: 2048
Key SHA1 Fingerprint: 11 E4 91 D1 C9 E4 C0 EB 9A CE CF 73 54 5D E1 F1 A8 30 3E C3
Public Key: 30 82 01 0A 02 82 01 01 00 D0 40 8B 8B 72 E3 91 1B F7 51 C1 1B 54 04 98 D3 A9 BF C1 E6 8A 5D 3B 87 FB BB 88 CE 0D E3 2F 3F 06 96 F0 A2 29 50 99 AE DB 3B A1 57 B0 74 51 71 CD ED 42 91 4D 41 FE A9 C8 D8 6A 86 77 44 BB 59 66 97 50 5E B4 D4 2C 70 44 CF DA 37 95 42 69 3C 30 C4 71 B3 52 F0 21 4D A1 D8 BA 39 7C 1C 9E A3 24 9D F2 83 16 98 AA 16 7C 43 9B 15 5B B7 AE 34 91 FE D4 62 26 18 46 9A 3F EB C1 F9 F1 90 57 EB AC 7A 0D 8B DB 72 30 6A 66 D5 E0 46 A3 70 DC 68 D9 FF 04 48 89 77 DE B5 E9 FB 67 6D 41 E9 BC 39 BD 32 D9 62 02 F1 B1 A8 3D 6E 37 9C E2 2F E2 D3 A2 26 8B C6 B8 55 43 88 E1 23 3E A5 D2 24 39 6A 47 AB 00 D4 A1 B3 A9 25 FE 0D 3F A7 1D BA D3 51 C1 0B A4 DA AC 38 EF 55 50 24 05 65 46 93 34 4F 2D 8D AD C6 D4 21 19 D2 8E CA 05 61 71 07 73 47 E5 8A 19 12 BD 04 4D CE 4E 9C A5 48 AC BB 26 F7 02 03 01 00 01


Subject Key Identifier
Key Identifier: 0B 58 E5 8B C6 4C 15 37 A4 40 A9 30 A9 21 BE 47 36 5A 56 FF
Critical: No


Key Usage
Usages: Digital signature
Critical: Yes
Basic Constraints
Certificate Authority: Yes
Max Path Length: Unlimited
Critical: Yes


Extension
Identifier: 2.5.29.31
Value: 30 40 30 3E A0 3C A0 3A 86 38 68 74 74 70 3A 2F 2F 63 72 6C 2E 63 6F 6D 6F 64 6F 63 61 2E 63 6F 6D 2F 43 4F 4D 4F 44 4F 43 65 72 74 69 66 69 63 61 74 69 6F 6E 41 75 74 68 6F 72 69 74 79 2E 63 72 6C
Critical: No


Signature
Signature Algorithm: SHA1 with RSA
Signature Parameters: 05 00
Signature: 3E 98 9E 9B F6 1B E9 D7 39 B7 78 AE 1D 72 18 49 D3 87 E4 43 82 EB 3F C9 AA F5 A8 B5 EF 55 7C 21 52 65 F9 D5 0D E1 6C F4 3E 8C 93 73 91 2E 02 C4 4E 07 71 6F C0 8F 38 61 08 A8 1E 81 0A C0 2F 20 2F 41 8B 91 DC 48 45 BC F1 C6 DE BA 76 6B 33 C8 00 2D 31 46 4C ED E7 9D CF 88 94 FF 33 C0 56 E8 24 86 26 B8 D8 38 38 DF 2A 6B DD 12 CC C7 3F 47 17 4C A2 C2 06 96 09 D6 DB FE 3F 3C 46 41 DF 58 E2 56 0F 3C 3B C1 1C 93 35 D9 38 52 AC EE C8 EC 2E 30 4E 94 35 B4 24 1F 4B 78 69 DA F2 02 38 CC 95 52 93 F0 70 25 59 9C 20 67 C4 EE F9 8B 57 61 F4 92 76 7D 3F 84 8D 55 B7 E8 E5 AC D5 F1 F5 19 56 A6 5A FB 90 1C AF 93 EB E5 1C D4 67 97 5D 04 0E BE 0B 83 A6 17 83 B9 30 12 A0 C5 33 15 05 B9 0D FB C7 05 76 E3 D8 4A 8D FC 34 17 A3 C6 21 28 BE 30 45 31 1E C7 78 BE 58 61 38 AC 3B E2 01 65


What happens at each of the subjects


1) Let's start with Root CA



2) This Self Signed Certificate is distributed to customers.


An example client is a browser. In any browser you can see a list of certificates.
For example in Chrome: Settings -> Manage Certificates -> Authorities.
Now the client knows about the existence of a CA.


3) Proof of Authenticity


If you do not go into details, then this item is the same for the Server and Intermediate Authentication Centers



As a result, we have a Self Signed Certificate on the client and a Signed Server Certificate on the server, i.e. the client knows and trusts the CA and CA has guaranteed the authenticity of the server.


4) Directly dialogue


Now let's see what happens when the client accesses the server. To do this, use the Network dump from Wireshark .




We see messages:
Client Hello, Server Hello, Change Cipher Spec, Encrypted Handshake Message


The following shows what these messages carry:



As you can see, along with Server Hello, the Client receives the Server Certificate Chain ( Server Certificate ).
How the client verifies the authenticity of the Certificate. How does this happen:
1) The client checks if he has a Root CA for the top certificate in the chain,
if not, it goes down the chain below, and each time it checks to see if the certificate was really signed by the previous one in the chain. (It's simple - the digital signature of the lower one must be decrypted with the public key of the upper one).
If you have not found it, then the Client and Server do not have a mutual familiar CA, you cannot trust the server.
2) if there is - the Client takes the Public Key of his certificate and tries to decrypt the signature of the certificate that came from the Server.



Note


TLS also supports the Server trust mechanism to the client. As you can see from Figure 5, in response to Server Hello, a client certificate can arrive, and the server can also verify that the CA has guaranteed its authenticity.


Conclusion


So, when both parties are convinced that their interlocutors are those whom they claim to be, you can begin the dialogue. Moreover, everything is immediately there for further message encryption - the private key on the server side, and its public key on the client, which was sent with the server certificate. But in the future, asymmetric encryption is used only once - when the client encrypts the password with the public key of the server, and sends it to the server - KlientKeyExchange . Further, this password is already used for symmetric encryption of messages, since it is much faster and easier than asymmetric. Mechanisms for choosing the encryption protocol and ensuring the integrity of messages are a huge area of ​​mathematics and cryptography, but, fortunately for the user, it is already implemented under the hood of SSL. All that is needed is that the client and server have compatible versions of SLL, cipher, and cryptographic providers.


In the end, I would like to say that the protocols of secure communication:



But the main, and perhaps sufficient, argument for - HTTPS and TLS are really as secure as possible.


Useful links on the topic
http://www.youdzone.com/signature.html
https://habrahabr.ru/post/258285/
https://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/
http://superuser.com/questions/126121/how-to-create-my-own-certificate-chain


')

Source: https://habr.com/ru/post/305748/

More articles:


All Articles