Transport Layer Security - TLS

Giriş
HTTP'nin eksiklikleri var. Açıklaması şöyle.  Yani HTTP "Man In The Middle Attack" saldırısına açık.

HTTP has no mechanism...
- to verify that you are actually connected to the server that you intend to connect to,
- or actually downloading the file that you expected to receive.

DTLS - Datagram Transport Layer Security

Yazıya başlamadan önce TLS alternatiflerinden bahsetme gerek :) TLS TCP kullanır, DTLS ise UDP kullanır. Açıklaması şöyle

DTLS is basically TLS, but for UDP. The reason you might want to use DTLS is because your application uses UDP instead of TCP (e.g. a VoIP program), but you still want your datagrams to be encrypted.

DTLS is not more or less secure than TLS, but instead is designed to work with a different underlying layer.

TLS - Transport Layer Security

Transport Layer Security 3 tane önemli şey sağlar. Confidentiality (Gizlilik), Integrity (Bütünlük), Authenticity (Sahicilik) Açıklaması şöyle

Confidentiality: that nobody can see the traffic between you and facebook.com (including the guy at the next table at Starbucks, your ISP, some sketchy network equipment in the datacentre COUGH NSA, nobody).

Integrity: that nobody is modifying the messages as they travel between you and facebook.com (this is separate from Confidentiality because some kinds of attacks allow you to modify the message in a malicious way even if you don't know what the messages are).

Authenticity: that you are talking to the authentic facebook.com server, not a spoofed version of it.

TLS ve E-Posta

Açıklaması şöyle. E-Posta tümüyle TLS kullanmadığı için, tam anlamıyla güvenli değil.

Mail delivery using TLS and signing using DKIM are weak protections, compared to accessing a web site using HTTPS. They should not be assumed to provide the same security and the indicators better should not suggest such interpretation.

..

Mail is delivered hop-by-hop between client and final mail server, i.e. there are multiple servers in between. TLS cares only about protection between these hops, not on these hops. Each of these servers has access to the plain unencrypted mail. The indicator in GMail shows only if the last hop of delivery was done over TLS - and this is all what the final mail server can control.

TLS ve Application Layer
HTTP isteğinin tamamı şifrelenir. Açıklama HTTPs için ancak TLS içinde geçerli. Açıklaması şöyle

HTTPS protects the whole HTTP request. The url path, the parameters, cookies, http headers, the body... The only thing it doesn't protect (other than tcp parameters like ip addresses and ports) is the hostname you are connecting to, which is leaked through the SNI extension (this should be fixed by tls-esni, just a draft for now)

TLS Layer 3'te de Kullanılabilir
TLS normalde Layer 3'ten yukarıda yani Application Layer'da kullanılır diye düşünüyoruz. Ancak daha alt seviyede de kullanılabiliyormuş. Açıklaması şöyle.

TLS is a protocol that has many different uses. The most common one is in HTTPS but many other protocols use it too as it's a standard way to encrypt network traffic. That's the application level.

In AWS Client VPN it's being used one level down - to encrypt the actual network layer traffic (level 3), regardless of what's passing through the tunnel. They chose to use TLS because it's a standard well known protocol.

SSL
Artık kullanılmamalı. Açıklaması şöyle.

30 June 2018 is the deadline for disabling SSL/early TLS and implementing a more secure encryption protocol – TLS 1.1 or higher (TLS v1.2 is strongly encouraged) in order to meet the PCI Data Security Standard (PCI DSS) for safeguarding payment data.

Sürümleri şöyle

SSL 1.0 (obsolete)
SSL 2.0 (obsolete)
SSL 3.0 (mostly obsolete)
TLS 1.0
TLS 1.1
TLS 1.2

TLS 1.1
Artık kullanılmamalı. Chrome Açıklaması şöyle

In Chrome 81, which will be released to the Stable channel in March 2020, we will begin blocking connections to sites using TLS 1.0 or 1.1, showing a full page interstitial warning:

TLS 1.2
TLS 1.2 internetteki varsayılan kripto. Açıklaması şöyle

TLS v.1.2 is the defacto standard for encrypted communications today. There are other protocols, like IPSEC, or even TLS v.1.3, but TLS v.1.2 is the default choice for web browsers at this point. And this makes it the most widely distributed encryption protocol ever.

Bir önceki sürüme yeni kripto ekliyor. Açıklaması şöyle.

TLS 1.2 did add new crypto, for example you can now use AES instead of 3DES, or ECDHE instead of DHE. At the moment, there are no known attacks against those ciphers so you can't directly say that it's for security. 1.2 also replaces MD5 and SHA1. That is a security improvement, but for something as short-lived as a TLS connection, it's unlikely to be a major weakness.

TLS 1.3
TLS v1.3 yazısına taşıdım.

TLS ve TCP
TLS altta TCP kullanır. Açıklaması şöyle

TLS requires a reliable transport. On the internet, this leaves only TCP, as UDP does not offer reliability.

TLS does require a reliable transport because (in compliance with the layered architecture of the ISO/OSI reference model) it does not handle transport errors, lost packets or other disturbances that may occur with IP.

TLS is designed to offer a secure channel on top of a reliable transport and it does this quite well. DTLS does (I assume) the necessary error handling within the protocol.

If TLS was to be performed over UDP, connections and handshakes could fail just because a packet got lost in transit and no one noticed.

TLS ve Overhead

Açıklaması şöyle

• he total overhead to establish a new TLS session comes to about 6.5k bytes on average
• The total overhead to resume an existing TLS session comes to about 330 bytes on average
• The total overhead of the encrypted data is about 40 bytes (20 + 15 + 5)
• It is easy to modify the above calculations to reflect more precisely the specifics of an environment, so this should be considered a basis for TLS overhead and not the authoritative answer to the question posed.

TLS ve Replay Protection

Açıklaması şöyle. Yani TLS çift gelen paketleri tespit edebilir.

There are multiple mechanisms to detect duplicates.

- At the TCP level there is the sequence number sent within each TCP packet, which allows to detect if a packet was received twice, or more generally if it overlaps with already received data. This is not actually a security feature but to detect packet reordering, duplication and loss and this way provide a reliable transport layer on top of an unreliable network layer. If such a duplicate gets detected it will simply be discarded.

- At the TLS level no sequence number are explicitly sent on the wire, but sequence numbers are still maintained inside the TLS state of each peer and are included in the computation of the payload protection. Thus TLS has a replay protection by design - see TLS sequence number for more. Since a successfully replayed packet essentially means that an attacker was able to actively fiddle with the underlying reliable TCP connection, this connection will usually be treated as compromised and abandoned.

- Additionally each new TLS session results in a different encryption key, i.e. the server would not be able to decrypt a HTTP request sniffed from a different TLS session in the first place. Thanks to user253751 pointing this out in a comment.

TLS ve Sıkıştırma (Compression)
Açıklaması şöyle.

...a famous attack, called CRIME, and has lead to TLS abandoning compression at the security protocol level.

Server Name Indication Eklentisi- SNI
Açıklaması şöyle. Kısaca TSL kullanarak bağlanmak istediğmiz sunucunun ismi SNI ile belirtilir.

HTTPS does not hide the server that is being accessed, because it needs the SNI (Server Name Indication) to be on the clear, so the server can know which certificate to use on the connection. Once the handshake is established, everything else is encrypted, including which page you are requesting.

Açıklaması şöyle

SNI (Server Name Indication) is a TLS (Transport Layer Security) extension in which the client presents the server the domain name for the target it wants to access within the TLS handshake. It is used in cases where there are multiple virtual servers with different certificates on the same IP address, so that the server can present the correct certificate.

Insofar it is similar to the HTTP host header in the HTTP request which is used to select the matching virtual host configuration - only that the Host header can not be used to select the certificate since it gets only sent inside the HTTP request. (i.e. after the TLS handshake is already done).

Since the SNI TLS extension is optional, some clients may not sent this extension. This is the case with openssl s_client without -servername argument but also with many TLS libraries in different programming languages. And while all modern browsers use SNI older browser like IE8 on XP do not use it.

If such a client connects to a server which has multiple certificates, the server does not know which certificate the client actually needs, i.e. the client falls into the "SNI hole" by not using the SNI extension. In this case the server usually either send an error back (or sometimes just closes the connection) or uses a default certificate explicitly or implicitly configured for this purpose.

Bu alana IP adresi yazılamaz. Açıklaması şöyle.

Literal IPv4 and IPv6 addresses are not permitted in "HostName".

Eğer istek içinde SNI belirtilmezse sunucu geçersiz sertifika dönebilir. Açıklaması şöyle.

That server apparently, like many today, supports multiple 'virtual' hosts with different certificates using the TLS extension 'Server Name Indication' aka SNI. If contacted using SNI for www.isi.gov.ie it provides a certificate which is valid for that domain and isi.gov.ie, but if contacted using no SNI it provides an expired certificate for the domains *.rdccremote.ie and rdccremote.ie;

Encrypted Server Name Indication Eklentisi

Açıklaması şöyle. Bir başka açıklama burada.

 It is part of the TLS 1.3 specification,...

mTLS 

Mutual TLS - mTLS yazısına taşıdım

TLS v1.3

Giriş
Bu sürüm ile Triple DES protokole dahil edilmiyor. Bu sürüm ile AES-CBC mod da protokole dahil edilmiyor. Protokole iyileştirme getiriyor. Açıklaması şöyle.

Because of the newer ciphers, you will get slightly less server load when using TLS 1.2. TLS 1.3 will offer improved performance at the protocol level as well. 

TLS ve IP Paketi
Açıklaması şöyle.

TLS doesn't protect the low level TCP/IP packets, which leaks information like the IP address of the machine you're connecting with, and the TLS handshake also by design leaks a number of information about the connection like Server Name Indication (SNI) header.

Null Cipher Suite

Eski TSL sürümlerinde olan bu cipher TLS v3 ile kaldırılıyor. Bu cipher şifreleme (encryption) değil sadece bütünlük (integrity) sağlıyordu. Açıklaması şöyle

SSL/TLS before 1.3 has some 'with-NULL' cipher suites that provide NO confidentiality, only authentication and integrity; see e.g. rfc5246 app C and rfc4492 sec 6 or just the registry. These do the usual handshake, authenticating the server identity using a certificate and optionally also the client identity, and deriving session/working keys which are used to HMAC the subsequent data (in both directions, not only from the server) but not to encrypt it. This prevents modification, or replay, but allows anyone on the channel/network to read it.

These cipher suites are very rarely used, and always (to the best of my knowledge) disabled by default. 

...

TLS 1.3 changes how cipher suites are used, and no longer has this functionality. As time goes on, 1.3 will become more widespread, and it is likely 1.2 and 1.1 will be dropped in the foreseeable future.

Client Hello Mesajı

Yapısı şöyledir

struct {
      ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
      Random random;
      opaque legacy_session_id<0..32>;
      CipherSuite cipher_suites<2..2^16-2>;
      opaque legacy_compression_methods<1..2^8-1>;
      Extension extensions<8..2^16-1>;
  } ClientHello;

Açıklaması şöyle.

The client sends a Client Hello handshake message in a TLS record containing:

 TLS Record - Version: minimum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not really used and MUST be 0x0303 ("TLS 1.2") or 0x301 ("TLS 1.0") for compatibility purposes. Reference: RFC 8446 (page 79)

 Client Hello - Version: maximum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not used but MUST be set to 0x0303 ("TLS 1.2"). Reference: RFC 8446 (4.1.2. Client Hello)

 Client Hello - Supported Versions Extension: list of supported versions. This is the only value used by TLS 1.3 implementations (which may agree TLS 1.3, 1.2 or other versions). Reference: RFC 8446 (4.2.1. Supported Versions)

legacy_version Alanı

Açıklaması şöyle.

In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. TLS 1.3 ClientHellos are identified as having a legacy_version of 0x0303 and a supported_versions extension present with 0x0304 as the highest version indicated therein. (See Appendix D for details about backward compatibility.)

Server Hello mesajı
Açıklaması şöyle.

The server sends a Server Hello handshake message with:

Server Hello - Version: negotiated version (for TLS 1.2 and before). If TLS 1.3 is negotiated, it MUST be set to 0x0303 ("TLS 1.2").
Server Hello - Supported Versions: a single negotiated version (for TLS 1.3). Cannot be used to negotiate earlier versions.