13:35 Tls / ssl inside and also why you can not configure https for virtual hosts | |
| TLS (which is the Transport Layer Security), he is formerly known as SSL (Secure Sockets Layer), is currently the de facto standard for protection of transport layer protocol of the various methods of intervention from outside. Few people do not use it, but am not sure that all is well imagine how it actually works and what features does, except the banal "as well, because it encrypts the channel between the client and the server." The SSL protocol developed by Netscape, to its development was to ensure the security of data transmitted by the transport layer model ISO / OSI. The latest version of the protocol - SSL 3.0 was published in 1996, and served as the basis for developing a protocol TLS, which began organizing IETF, and the result of this work was RFC 2246: The TLS protocol, version 1.0, released in 1999. At the moment, published RFC 5246: The TLS protocol, version 2.0, which extends the functionality of some of the first version, but leaving the essence unchanged. Operates over TLS transport protocol, for example (and often) TCP. Roughly speaking, it operates with two streams of data, regardless of their nature - the incoming and outgoing, and each of them converts to properly encrypted traffic (though there will be more accurate to say "change" as TLS permits and the lack of encryption of data transferred ). The protocol is divided into two stages: key exchange, and further sharing of data. The first stage takes place without any "useful" data sent from client to server and back, and serves to identify the client and server, as well as the choice of algorithms and initialization keys for future encryption. The second stage is just an exchange of data through the established logical connection, where each packet payload is encrypted (if encryption is enabled), is protected by MAC, and the other party through the underlying protocol (TCP). Proceed to a more detailed description of the first part of the protocol, as the most important. Initialise the communication between client and server communication ClientHello, which is sent from client to server. In this communication, customer lists supported them "protection algorithm" (in order of preference), and passes some of the other options (supported by data compression algorithms, 28 bytes of random data, which then will be used to generate a shared secret, session ID if you wish to restore it, in general about all this will happen in the text). Each "protection algorithm" rather cipher suite (if anyone has an idea how to translate into Russian in two words - please let us, "a set of algorithms," somehow does not sound), in fact, identifies the three algorithms: 1) key exchange algorithm, through which the client and server, after some manipulation, common 48-byte secret sharing, which are later used to generate keys for all other algorithms (encryption and MAC) 2) block or stream cipher algorithm used for encryption data 3) MAC - the algorithm used to calculate the MAC-code messages (identified by a hash algorithm, as described in the standard only HMAC). Receiving this message, the server selects a cipher to be used, according to its table of preferred cipher suites, and sends the client a message ServerHello. In addition to a selected set, the server also sends its generated random data and the ID of the session. Immediately after this message the server, depending on the selected set of algorithms that send (or send) the following message: Certificate, ServerKeyExchange, CertificateRequest. While ServerKeyExchange depends on the chosen key exchange algorithm and its contents to us at this stage is not interesting, Certificate & CertificateRequest very important for those who in general want to understand how it works, but tries to avoid excessive detail. In the message Certificate server sends its X.509 certificate, which certifies the authenticity of the server, and CertificateRequest - server requires the client to also send its certificate to trust its authenticity. In addition to the certificate, the server also (in the package ServerKeyExchange) sends the digital signature data sent in this package that allows you to make sure that this package actually sent to the server that owns the private key had been sent to the certificate. Yes, here we must remember (or write) that the x.509 certificate is binding a public key to an entity (person, organization, or, as in this case - a server), which owns the private key corresponding to this open . Certificates are self-certified (self-signed), when a person signs it himself, and certified by a CA. The main question that arises when dealing with such a certificate - trust in him, and then you can rely on, or their personal data (as in the case of self-certified certificates - anyone can generate such certificate), or trusted authority that imposes its signature the certificate, thus proving, as it were, that they checked, and that the certificate really corresponds to something and that something. For more details about how we, the face will be on, but in the meantime, we would return to ServerCertificate. So, the server sends its certificate and the client checks to see whether he really trusts this certificate, and if not, terminates a communication session. If the server requested a certificate from the client, the client must show your own certificate, otherwise the connection will already be closed by server. As a rule, the latter is used quite often (well, for example, WebMoney), and clients are authenticated to the server using a login and password. After getting this all the client sends a packet Certificate (if necessary), ClientKeyExchange, CertificateVerify (digital signature generated client certificate). All. After that, if passed peer review, it is believed that the client and server share a common secret, the dimension of 48 bytes. From this secret sharing, with transfers to these random data, and some constants, according to some rules (which I certainly do not describe here, this is a purely technical details, and the article is already long turned out), generated keys for encryption and verification of MAC code (it's worth it to write earlier, in general, MAC-code is something like a hash, but who can successfully check just having some extra key), and further there is exchange of data as provided for application-level protocol. For HTTPS - is sent by the client request, the server generates a response and sent back. More clearly and briefly the operation of the protocol can be represented by the following scheme: So, now how and what we can see or configure in the use of TLS: 1. Exchange of certificates. If the server sends a certificate that is not certified with a root CA known to your computer (mobile phone, smart phones, wristwatches, etc.), your device, depending on the settings, but usually ask "Do you trust and such a certificate? "to which almost everyone mindlessly answer" yes ", dashing all (well, except that in addition to the banal analysis sniffer) security, the proposed protocol TLS. Such as is done in WebMoney - I was very surprised when they offered me * your * Rutaceae certificate that I could do nothing to check, but theirs site. 2. Server certificate. And how do we actually know that the certificate matches this site? Know, because for TLS certificates in the common name (CN =) prescribes the name of a site that it corresponds to which browser should check for, and the resulting mismatch talk about error checking. Hence, by the way and get the problem with the fact that on a virtual server on one port can only be one HTTPS-site: for initializing the connection server must send a certificate to the desired host (if one considers that the server is able, in the Apache set up just one certificate, as far as I know of), and the correct host will be announced only later, in the Host: HTTP-request. At the moment, though there is an extension of the protocol TLS Server Name Indication, described in RFC 3546 (thanks for the tip-off IchBinFrei), but how it is used and maintained now, you should still check. In addition, the certificate can not only conform to one name server, and multiple sub-domains, in the form *. host.com 3. Client certificate. Well, everything is simple - the certificate that somehow must be saved on the server in the list of trust or authority, written out, this certificate should be trusted on the server. 4. Performance. In addition, the initialization of the protocol requires three parcels of data to and fro (ie it is already 3 ping), still plenty of time required to generate a digital signature (we consider the server side) as well as opening up the keys for symmetric encryption algorithms, for a total It may take more than half a second (by the way, it should be noted that the generation of DSA-signature in the amount equal to the RSA-key, there are 2-4 times faster). And if a page at the same loaded yet, and 30 pieces of pictures, so there's time to think about keep-alive, and about the tls session resumption (ie, the continuation of the session by its ID, which is sent to ClientHello). About it, I unfortunately do not have more data, it is actually used by browsers and servers, and how will the time, test and write. That seems to be so far everything if you have questions - always happy to answer. | |
|
| |
| Total comments: 0 | |