• S stands for secure, HTTPS is not a separate protocol
  • HTTP is a protocol, HTTPS is not a separate protocol, it is just HTTP built on top of SSL.

Definition 1.

  • HTTP over SSL/TLS/Secure
    • SSL: Secure Socket Layer (early)
    • TLS: Transport Layer Secure (Now)
  • It’s the same thing, it’s a layer of security underneath HTTP, and it’s essentially encrypting your HTTP messages before they’re sent and decrypting them after they’re received.
  • It is below the HTTP layer and above the TCP layer if it is to be categorized. A little bit closer to the application layer.

Nature of 2.

  • A symmetric key is negotiated between the client and the server, encrypted before each transmission, decrypted after receiving, to achieve encrypted transmission of content.
  • Asymmetric encryption is first used to transmit the symmetrically encrypted key, and then symmetric encryption is used to transmit the content of the communication.

3. Why not just use asymmetric encryption?

  • Because asymmetric encryption is slow, the math makes it slow. His calculations are complicated. So if we can use symmetry, we can use symmetry.
  • But the symmetric key can not be transmitted, how to do? I first used the asymmetric type of the key to discuss, to confirm, both sides got the key, with symmetric encryption transmission.
  • It’s a combination of safety and efficiency.

4. The process

General process:

  • First, your client requests a TLS connection over TCP, not HTTP.
  • Two, the server sends you his certificate.
  • Third, the client verifies that the server certificate is genuine.
  • The client trusts the server and negotiates the symmetric key with the server.
  • Five, use the symmetric key to initiate communication. Only the last step is HTTP communication, and all the others are TCP

Specific process:

  1. So first my Client will say to the server, I want to establish a connection, “Client Hello,” and send a very simple message to the server that I want to establish a connection.

    • At the same time, the client will attach a message, including what way I can communicate, I can accept the TLS version (because SSL was in the early TLS, their lower encryption methods have versions), this is a lot of information, several, is a sequence, for example, I support TLS 1.0/1.1/1.2, I also support SSL 3.0, I will send you, you choose.

    • It will also send a Cipher Suite, which is actually both symmetric and asymmetric encryption, and hash algorithms that I can accept. It’s an encryption suite, so why attach hash algorithms?

      • Hash itself can’t do encryption, but it participates in the encryption process, and it can do authentication.

    • At the same time, a random number is thrown, which is used later to calculate the secret key.

  1. And the Server says, okay, what is “Server Hello”? He just sends a byte, like client Hello is like 1 or something. It is a concrete byte.

    • At the same time, the server will choose which TLS you support, I will choose my favorite, including the algorithm behind. In fact, the next three algorithms are all packaged, so you can only pick one. Once the Server is selected, it will be sent back with Server Hello. And then they both hold this thing.

    • At the same time, the server will attach a random number to the client, so each side has a random number.

  1. And then the server sends something with it, the server certificate

    • The core of the certificate he issued was his public key, his asymmetrically encrypted public key.

    • Client needs to do to the public key authentication, because these are all proclaimed in front, he may be intercepted, so he need to verify that the server access server is what I think, so the server sending is not only a public key, but a certificate, the certificate contains the server’s public key.

    • It also contains the address of the server, which is the domain name, and then the client is going to validate that domain name so if I’m going to hencoder.com, I’m going to verify that the information that you’re returning is the information that I’m looking for, and the name of the server and so forth. Then why should I believe you when you say the server address is yours? I visit Hencoder.com, and some bad guy intercepts the message. After intercepting the message, he sends me back a certificate, which belongs to Hencoder.com, so I believe it? I’m sure I don’t. I’d be too easy to hack if I believed that easily. So that’s not enough. So what do we need?

    • He also needs to provide a proof that this thing is real. He was able to prove that my server information was real. What does that take? He needs to provide a signature. I can verify that the signature is correct, so I can confirm that the message sent by the server is indeed authentic. And this signature is to sign all the information of the signature. So the server address, the public key and so on can be proved.

  • How do I verify this signature?
    • The server will send me information about the signer of the certificate, the certificate authority. I have the certificate authority’s public key, which can verify the certificate signature and prove that the server’s information is indeed real.
    • But this is true with the assumption that the information in blue is actually signed by the yellow certificate authority, is actually signed by the private key holder of this public key. It is indeed signed by the owner of the public key, so you still can not prove that you are real, otherwise I will also create a certificate authority public key, certificate authority information is also created by me, and then the blue certificate information is also created by me, it is ok, I create a public key private key pair is not finished?
    • This time can only prove that the blue message is signed by the owner of the yellow.

  • At this point, there is a final step, which is that your certification authority also needs to provide proof information. He needs to provide who he signed with. His issuer’s information (circular?) That’s it. That’s it. Why stop there?

  • Let’s show this through a website certificate. We click on an HTTPS website, click on this lock, and this lock is his signature information, it’s HTTPS information, and then I click on this certificate.

  • The selected part is blue, the middle part is the secondary issuing authority, which is the yellow part, the top part is the issuer of the innermost certificate authority, which is the root certificate authority, which is called root certificate Authority, and this is the end of the certificate authority.
  • So how do I know the root certificate authority is real? What if this is a fake, too? You can nest me three layers and be safe?

  • Authentication of the root certificate can be found from a reliable source. From where?
    • From within the operating system. Every single one of our operating systems, ios, Android, MAC, Windows, we find this thing. We all have a list of root certificates stored on our computers or mobile phones. Look at my machine – keychain – system root certificate, and then find the same certificate on the website above. I have the root certificate in my system, so I can prove that he was signed by the root certificate. Because the root certificate has his public key in it. Then you can prove that the certificate authority information in yellow is indeed signed by the root certificate.

  • So one more question? How can your root certificate be trusted? Where does the root certificate come from?

    • The root certificate was created with our operating system. The list of root certificates existed when the operating system was packaged and issued, and it was verified by our operating system developer. So Microsoft, Apple, Google, or any of the browsers, authenticate these agencies, and then put it in the root certificate list of our operating system, or our browser, that their identity, their security, is guaranteed by the browser or the operating system. So as long as our operating system doesn’t get killed, our browser doesn’t get killed, this thing is safe.

    • A few years ago, alipay required users to install a root certificate, so as to ensure security. There was a saying, and then the media said, in fact, this is very unsafe. Security is not safe, I think it is safe, because alipay they do not need to do this bad thing, but I just from the fact that he will not do bad things, but if he wants to do bad things, we can not stop. He can sign it to any agency he wants. When he signs off on this, it’s safe. This site is safe.

    • In addition, wasn’t the root certificate authority directly blacklisted recently? Actually, what do you call this thing? A chain of trust has to have a place where you don’t need any proof, you need unconditional trust. It’s a fact that there’s no way that you can have a complete, proof only way of proving that it’s 100% reliable. There is always a deep place where you need to trust unconditionally. Then our list of root certificates is where we need to trust them unconditionally.

    • To review: That’s what the certificate looks like, my certificate has my server address in it, you can verify, you can verify that the server THAT I want to access is really the one THAT I want, it’s really Hencoder.com, it’s not someone trying to trick me with their legitimate certificate, it’s not true, it must be my target, And then how can I be sure that he is truly legitimate? He has one of his issuing agencies (yellow), how does your issuing agencies confirm that it is true? This issuing authority is going to specify its issuing party, and this issuing party’s public key is not in here, it’s in my system. It is in the system root certificate. At this point my server validation is done. The middle authority can be removed and you can simply ask the issuer to sign the server, but most schemes now have an intermediate authority because the root certificate authority is busy. This is the server certificate validation process.

  1. Then the client gets the public key of the server, and it does the only asymmetric encryption of the encryption process.
    • He would use the public key to encrypt a message and send it to the server. Encrypt what?
    • Encrypt something called per-master Secret, which is also a random number, and now there are three random numbers, and they have different names, and they have different identities. Per-master Secret is passed through a single asymmetric encryption. It was also the first encryption.

  1. Now both sides have three random pieces of information. At this point both parties have enough information to produce their symmetric keys.

    • So this is a symbolic step, he sends per-master Secret, and at this point they can produce something called master Secret, and that master Secret will produce their key directly. It’s not a key, because there are several things about keys. Per-master Secret is used with client-side random number and server-side random number. Through an algorithm, a new value is obtained. This value is called master Secret.

    • So here’s the question, why do you want to take those two random numbers to calculate?

      • What does that really do? When you’re on the road, people can see you. What are you gonna do with them? So this is the security thing, they think mathematically, even though you can see it, but I can actually add these two to make my key more secure. (Just know that).

    • Now that they have the Master Secret, they can use it to calculate their key. But the key is four things, actually six, but the other two are useless. What is it?

      • Client encryption key,
      • Server-side encryption key,
      • The client hash key,
      • There are four hash keys used by the server.

  • Why do clients and servers encrypt with two things?

    • Again, to prevent thieves, you send me a message, I send you a message, with a different key, a little more secure. For example, I sent a message to the server from the client, others cut him is not understand, it doesn’t matter I don’t understand I give you trouble, I don’t send to the server, I send you back intact, let you think that this is the server to you respond to the message. Then the client will be confused. What do you mean by sending me this? And it does seem okay to decompress.

  • What is MAC Secret?

    • Let’s talk about HMAC. MAC Secret is HMAC Secret.
      • HMAC: Hate-based Message Authenticate Code
      • It’s a modified hash. How does it work?
        • We do MD5,
        • MD5(a)=b
        • HMAC(a)=MD5(fun(a))=c
      • Hmac inside the specific things to do will be a bit more complex, he will be on your original message processing to do. He will do something to your A to make the hash harder to crack. One of the important things is that he adds something to it, like the hash we’re talking about he adds salt. This salt is known only to the communication parties, not to the others. My sender knows, my receiver knows, and no one else does.
      • What’s the difference? I can make this hash, no one else can make this hash, because you don’t have my password, you don’t have my Secret. If I hash this out, I can prove that it’s actually me.
      • So how do you verify that? You have the message, you are the client, you send the message, I am the server, AFTER I receive the message, I also have an HMAC for the message, and then I get the HMAC, I can verify the HMAC sent by the client together with the message, whether the two are consistent. If they are, I can be sure that the message was indeed sent to me by the client.
    • Encryption keys are used for encryption, MAC Secret is used for authentication.
      • You see we do asymmetric encryption, you use public key encryption, private key decryption for encryption, private key encryption, public key decryption for signature and authentication.
      • Symmetric encryption is encrypted with encryption keys, using HMAC to do signature and authentication, which is equivalent to a signature and authentication, actually not, but their purpose is the same. Can be used to verify identity. This Secret is not a signature, but a tool for authenticating your identity.

  • Having said that, these four keys are used to encrypt and verify identity.

  1. At this point the client can send encrypted messages. At this point, they need to verify that the encryption algorithm works.

    • The client says: I’m going to use encrypted communication.

  2. Sent by the client: Finished

    • This is not such a letter, and Clinet Hello is not a byte, this is a lot of messages.
    • He’s gonna wrap it all up and use the encryption key to encrypt it,
    • Using HMAC is the equivalent of signing, doing a hash, and sending the entire message to the server.
    • When the server gets it, it’s going to look at what it is, and THEN I’m going to verify that the signature is appropriate.
    • If he can both read it and sign it correctly, your server can trust the client enough. No one lied to me. No one played tricks. The client can send me messages.

  3. Again, the server will send it next. The server says: I’m going to use encrypted communication.

  4. The server says “Finished”, which is similar to the client’s “Finished” message. It’s just that he packs a little more. And then send it to the client, and then the client does the same authentication. I’m going to do some HMAC. Let’s see if my HMAC is the same as yours. If you are, you are who you are. And I’m gonna use your encryption key to see if it works. This is the time to prove that my encryption is also available.

  • At this point, the authentication is complete and the client sends an HTTPS request to the server. This is the first HTTPS request. And then he looks like this.

  • From TCP’s point of view, that’s what he’s writing, and from HTTP’s point of view, there’s no way to parse it, but from other people’s point of view, all he knows is that this is an application layer message sent by TCP, but I don’t know what it is. I don’t even know if this is an HTTP message. Because it’s completely encrypted by HTTPS using the key. Similarly, when the server receives it, he can understand it, and his reply message looks like this. That’s all they see, he doesn’t even know if it’s HTTP, he doesn’t understand it at all, but he knows it’s a TCP message. Because encryption is encrypted on top of TCP. So you can read it at the TCP level. But that’s about it.

Conclusion:

  • 1. The client sends a supported encryption suite and a random number
  • 2. The server selects a random number and sends a certificate
  • 3. Client certificate authentication, system root certificate, asymmetric encryption, send and encrypt the quasi-primary secret information, which is also a random number
  • 4. Three random numbers, two pairs of keys and hash keys are generated on both sides
  • 5. The client says to send an encrypted message
  • 6. The client said finished
  • 7. The server sends encrypted messages
  • 8. The server said finished

Use in Android

  • It’s ok to use it normally.

  • Sometimes it doesn’t:

    1. Self-signed certificates, certificates are hung on the website, how to hang you do not need to know, just like you do not need to know how to develop a server. On the website, sometimes the certificate does not attach the organization information, just put a public key of their own, why? Because sometimes web pages are self-signed. Self-signing is when your client authenticates your message, not with your local root certificate authority. So this is usually used on the Intranet. Like the campus network or something, they’re going to ask everyone to put on our credentials. And then you can access the Intranet, and that’s how it works.

    2. The certificate information is incomplete. Your certificate did not adjust well, it is also possible, because they said it is too complicated, in short, because they can omit some things, so they omit, but this can omit the content can not be provided from the outside, finished, certificate agency information is missing, it is still considered not feasible.

    3. Mobile operating systems are older. Such as you use a 12 years of operating system, over the years hasn’t been updated root certificate, and then to a relatively new certificate authority, set up 18 years, he signed the certificate can’t read your old mobile phone, he thought you this thing is illegal, because all of my system inside the root certificate of the no sign to him, so I don’t think you legally.

  • How to do?

    • Write your own certificate verification process. Google android HTTPS. This site has developer.android.com/training/ar…

  • If you understand the above, you should be able to understand it. It might just take a little time.