Transport Layer Security: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(65 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== TLS and its support mechanisms ==
'''Transport Layer Security''' (TLS) - Transportschichtsicherheit


=== HTTP Strict Transport Security (HSTS) ===
== Beschreibung ==
HTTP Strict Transport Security (HSTS) is a web security policy mechanism. HSTS is realized through HTTP header by which a web server declares that complying user agents (web browsers) should interact with it by using ''only'' secure HTTPS connections. [[https://bettercrypto.org/#_footnotedef_33 33]]
{| class="float wikitable"
HSTS header is bound to a DNS name or domain by which the server was accessed. For example if server serves content for two domains and it is HTTPS enabled only for one domain, the browser won’t enforce HSTS for the latter.
|+ TLS im [[TCP/IP-Referenzmodell|TCP/IP-Protokollstapel]]
HSTS reduces the risk of active man-in-the-middle attacks such as SSL stripping, and impersonation attacks with ''untrusted'' certificate. HSTS also helps to avoid unintentional mistakes such as insecure links to a secure web site (missing HTTPS links [[https://bettercrypto.org/#_footnotedef_34 34]]), and mistyped HTTPS URLs.
|- style="background:#DDDDFF;"
After the web browser receives a HSTS header in a ''correctly'' [[https://bettercrypto.org/#_footnotedef_35 35]] prepared SSL session it will automatically use secure HTTPS links for accessing the server.
|style="background:#FFEEBB"| ''Anwendung''<br />
This prevents unencrypted HTTP access (SSL striping, mistyped HTTPS URLs, etc.) when the server is accessed later by the client.
| [[Hypertext Transfer Protocol Secure|HTTPS]]
When a server (that previously emitted a HSTS header) starts using an untrusted certificate, complying user agents must show an error message and ''block the server connection''. Thus impersonation MITM attack with ''untrusted'' certificates cannot occur.
| [[Internet Message Access Protocol#IMAPS|IMAPS]]
For the initial setup HSTS header needs a trusted secure connection over HTTPS. This limitation can be addressed by compiling a list of STS enabled sites directly into a browser. [[https://bettercrypto.org/#_footnotedef_36 36]]
| [[POP3S]]
| [[SMTPS]]
| …
|-
|style="background:#FFCC99;"|
|colspan="5" style="background:#9999FF"| '''TLS'''
|-
|style="background:#FFEEBB;"| ''Transport''
|colspan="5" style="background:#EEEEEE;"| [[Transmission Control Protocol|TCP]]
|- style="background:#EEEEEE;"
|style="background:#FFEEBB;"| ''Internet''
|colspan="5"| [[Internet Protocol|IP]] ([[IPv4]], [[IPv6]])
|- style="background:#EEEEEE;"
|style="background:#FFEEBB"| ''Netzzugang''
| [[Ethernet]]
| [[Token Bus|Token<br />Bus]]
| [[Token Ring|Token<br />Ring]]


==== HSTS Header Directives ====
| [[Fiber Distributed Data Interface|FDDI]]
HSTS header can be parametrized by two directives:* max-age=<number-of-seconds>
| …
* includeSubdomains
|}
''max-age'' is a required directive. This directive indicates the number of seconds during which the user agent should enforce the HSTS policy (after the reception of the STS header field from a server).
'''Transport Layer Security''' ('''TLS''', {{enS}} für „Transportschichtsicherheit“)
''includeSubdomains'' is an optional directive. This directive indicates that the HSTS policy applies to this HSTS host as well as ''any subdomains of the host’s domain name''.


==== HSTS Client Support ====
* Bekannt unter der Vorgängerbezeichnung '''Secure Sockets Layer''' ('''SSL''')
HSTS is supported [[https://bettercrypto.org/#_footnotedef_37 37]] by these web browsers:* Firefox version >= v4.0
* [https://de.wikipedia.org/wiki/Verschl%C3%BCsselungsprotokoll Verschlüsselungsprotokoll] zur sicheren [https://de.wikipedia.org/wiki/Daten%C3%BCbertragung Datenübertragung] im [https://de.wikipedia.org/wiki/Internet Internet]
* Chrome version >= 4.0
* Android Browser >=4.4
* Opera version >= 12.0
* Opera mobile >= 16.0
* Safari >= 7.0
* Microsoft Internet Explorer >= 11 (with update provided 09. June 2015)
* Microsoft Edge >= 12


==== HSTS Considerations ====
; Hauptkomponenten
Before enabling HSTS it is recommended to consider following:* Is it ''required'' to serve content or services over HTTP?
TLS besteht aus den beiden Hauptkomponenten TLS Handshake und TLS Record
* Enabling ''includeSubdomains'' and SSL certificate management.
* Im TLS Handshake findet ein sicherer [https://de.wikipedia.org/wiki/Schl%C3%BCsselaustausch Schlüsselaustausch] und eine [https://de.wikipedia.org/wiki/Authentifizierung Authentifizierung] statt
* Proper value of ''max-age''.
* TLS Record verwendet dann den im TLS Handshake ausgehandelten symmetrischen Schlüssel für eine sichere Datenübertragung – die Daten werden verschlüsselt und mit einem [https://de.wikipedia.org/wiki/Message_Authentication_Code MAC] gegen Veränderungen geschützt übertragen
It is recommended to serve all content using HTTPS, but there are exceptions to this rule as well. Consider running a private PKI [[https://bettercrypto.org/#_footnotedef_38 38]]. CRLs and OCSP responses are published typically by HTTP protocol. If HSTS is enabled on the site where OCSP and CRLs are published the browser might fail fetching CRL or validating OCSP response.
Similar reasoning goes for ''includeSubdomains''. One needs to be sure that HTTPS can be enforced for all subdomains. Moreover the administrators are advised to watch for expiration of the SSL certificate and handle the renewal process with caution. If a SSL certificate is renewed after expiration or misses a (HSTS enabled) domain name, the connection to site will break (without providing override mechanism to the end user).
Finally HSTS should be tested with lower ''max-age'' values and deployed with higher ''max-age'' values.


==== Testing HSTS ====
; Schlüsselaustausch
HSTS can be tested either using locally or through the Internet.
Für den [https://de.wikipedia.org/wiki/Schl%C3%BCsselaustausch Schlüsselaustausch] sind in den älteren TLS-Versionen verschiedene Algorithmen mit unterschiedlichen Sicherheitsgarantien im Einsatz
For local testing it is possible to utilize Chrome Web browser UI by typing chrome://net-internals/#hsts [[https://bettercrypto.org/#_footnotedef_39 39]] in the address bar.
* Die neueste Version TLS 1.3 verwendet allerdings nur noch das [https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch Diffie-Hellmanprotokoll] (DHE oder ECDHE)
Testing over the Internet can be conducted by Qualys SSL Labs test [https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/]. ''Strict Transport Security (HSTS)'' information is located in the ''Protocol Details'' section.
* Dabei wird für jede Verbindung ein neuer [https://de.wikipedia.org/wiki/Session_Key Sitzungsschlüssel] (Session Key) ausgehandelt
* Da dies ohne Verwendung eines Langzeitschlüssels geschieht, erreicht TLS 1.3 [https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Perfect Forward Secrecy]


==== References ====
=== Vor- und Nachteile ===
* Websites Must Use HSTS in Order to Be Secure: [https://www.eff.org/deeplinks/2014/02/websites-hsts https://www.eff.org/deeplinks/2014/02/websites-hsts]
Der Vorteil des TLS-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des TLS-Protokolls zu implementieren
* OWASP: HTTP Strict Transport Security: [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security https://www.owasp.org/index.php/HTTP_Strict_Transport_Security]
* Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet
* HSTS Browser Compatibility List: [https://caniuse.com/stricttransportsecurity https://caniuse.com/stricttransportsecurity]
* RFC 6797:HTTP Strict Transport Security (HSTS) - Examples: [https://tools.ietf.org/html/rfc6797#section-6.2 https://tools.ietf.org/html/rfc6797#section-6.2]


=== HTTP Public Key Pinning (HPKP) ===
Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist
Much like HTTP Strict Transport Security (HSTS), HTTP Public Key Pinning (HPKP) is a Trust-On-First-Use (TOFU) mechanism. It protects HTTPS websites from impersonation using certificates issued by compromised certificate authorities. The data for Pinning is supplied by an HTTP-Header sent by the WebServer.
* Die Verschlüsselung selbst beansprucht je nach verwendetem [https://de.wikipedia.org/wiki/Algorithmus Algorithmus] nur wenig Rechenzeit


==== HPKP Header Directives ====
Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf [https://de.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol PPTP]-Ebene) kaum durch Kompression zu verdichten
HPKP provides two different types of headers:* Public-Key-Pins
* Public-Key-Pins-Report-Only
HPKP header can be parametrized by following directives:* pin-sha256="<YOUR_PUBLICKEY_HASH⇒"
* max-age=<number-of-seconds>
* includeSubdomains
* report-uri="<[https://YOUR.URL/TO-REPORT%3E https://YOUR.URL/TO-REPORT>"]
'''pin-sha256''' is a required directive. It can and should be used several (at least two) times for specifying the public keys of your domain-certificates or CA-certificates. Operators can pin any one or more of the public keys in the certificate-chain, and indeed must pin to issuers not in the chain (as, for example, a backup-pin). Pinning to an intermediate issuer, or even to a trust anchor or root, still significantly reduces the number of issuers who can issue end-entity certificates for the Known Pinned Host, while still giving that host flexibility to change keys without a disruption of service. OpenSSL can be used to convert the public-key of an X509-certificate as follows:
$ openssl x509 -in <certificate.cer> -pubkey -noout |
  openssl rsa -pubin -outform der |
  openssl dgst -sha256 -binary |
  openssl enc -base64
writing RSA key
pG3WsstDsfMkRdF3hBClXRKYxxKUJIOu8DwabG8MFrU=
This piped usage of OpenSSL first gets the Public-Key of <certificate.cer>, converts it do DER (binary) format, calculates an SHA256 Hash and finally encodes it Base64. The output (including the ending Equal-Sign) is exactly whats needed for the ''pin-sha256="<YOUR_PUBLICKEY_HASH⇒"'' parameter.
To generate the hash for a prepared backup-key just create a certificate-signing-request and replace <tt>openssl x509</tt> by <tt>openssl req -in <backup-cert.csr> -pubkey -noout</tt> as first OpenSSL command.
Instead of using OpenSSL even web-services like [https://report-uri.io/home/pkp_hash/ https://report-uri.io/home/pkp_hash/] can be used to get a suggestion for the possible Public-Key-Hashes for a given website.
'''max-age''' is a required directive (when using the ''Public-Key-Pins'' header). This directive specifies the number of seconds during which the user agent should regard the host (from whom the message was received) as a "Known Pinned Host".
'''includeSubdomains''' is an optional directive. This directive indicates that the same pinning applies to this host as well as ''any subdomains of the host’s domain name''. Be careful - you need to use a multi-domain/wildcard-certificate or use the same pub/private-keypair in all subdomain-certificates or need to pin to CA-certificates signing all your subdomain-certificates.
'''report-uri''' is an optional directive. The presence of a report-uri directive indicates to the web-browser that in the event of pin-validation failure, it should post a report to the report-uri (HTTP-Post is done using JSON, Syntax see {RFC-7469 Section 3} [[https://bettercrypto.org/#_footnotedef_40 40]]). There are WebServices like [https://report-uri.io/ https://report-uri.io/] out there which can be used to easily collect and visualize these reports.


==== HPKP Client Support ====
TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen
HPKP is supported [[https://bettercrypto.org/#_footnotedef_41 41]] by these web browsers:* Firefox version >= 35
* Es sind Szenarien in [https://de.wikipedia.org/wiki/Serviceorientierte_Architektur serviceorientierten Architekturen] denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird
* Chrome version between version 38 and 72
* Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann
* Android Browser >= 44
* Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann
* Opera version >= 25
Currently (20. Dec 2018) there is no HPKP support in: Apple Safari, Microsoft Internet Explorer and Edge. HPKP Support has been removed from Google Chrome and Chromium from version 72 onwards.


==== HPKP Considerations ====
== Implementierungen ==
Before enabling HPKP it is recommended to consider following:* Which Public-Keys to use for Pinning (Certificate + Backup-Certificate, CAs, Intermediate-CAs)
Zu den bekanntesten [https://de.wikipedia.org/wiki/Programmbibliothek Programmbibliotheken], die Transport Layer Security implementieren, gehören:
* Proper value of ''max-age''. Start testing with a short Period, increase Period after deployment.
* Be careful when using ''includeSubdomains'', are all your subdomains covered by the defined Public-Key-Hashes?
The administrators are advised to watch for expiration of the SSL certificate and handle the renewal process with caution.
If a SSL certificate is renewed without keeping the public-key (reusing the CSR) for an HPKP enabled domain name, the connection to site will break (without providing override mechanism to the end user).


==== Testing HPKP ====
* [https://de.wikipedia.org/wiki/OpenSSL OpenSSL]
HPKP can be tested either using locally or through the Internet.
* [https://de.wikipedia.org/wiki/GnuTLS GnuTLS]
There is a handy bash-script which uses OpenSSL for doing several SSL/TLS-Tests available at [https://testssl.sh/ https://testssl.sh/]
* [https://de.wikipedia.org/wiki/LibreSSL LibreSSL]
$ wget -q https://testssl.sh/testssl.sh
* [https://de.wikipedia.org/wiki/Network_Security_Services Network Security Services]
$ wget -q https://testssl.sh/mapping-rfc.txt
* [https://de.wikipedia.org/wiki/Mbed_TLS mbed TLS], vormals PolarSSL
$ chmod 755 ./testssl.sh
* [https://de.wikipedia.org/wiki/OpenSSL#Abspaltungen BoringSSL]
$ ./testssl.sh https://example.com
* [https://de.wikipedia.org/wiki/Cryptlib Cryptlib]
<nowiki># Sample Output, just HSTS and HPKP Section (Full report is quite long!):</nowiki>
* [https://de.wikipedia.org/wiki/SChannel SChannel] (Microsoft)
Strict Transport Security   182 days=15724800 s, includeSubDomains
* [https://de.wikipedia.org/wiki/WolfSSL WolfSSL]
Public Key Pinning # of keys: 2, 90 days=7776000 s, just this domain
            matching host key: pG3WsstDsfMkRdF3hBClXRKYxxKUJIOu8DwabG8MFrU
For local testing it is possible to utilize Google Chrome web-browser, just open the Chrome net-internals-URL: chrome://net-internals/#hsts.
For Mozilla Firefox there is an plug-in provided by the "Secure Information Technology Center Austria" available: [https://demo.a-sit.at/firefox-plugin-highlighting-safety-information/ https://demo.a-sit.at/firefox-plugin-highlighting-safety-information/]
Testing over the Internet can be conducted by Qualys SSL Labs test [https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/]. ''Public Key Pinning (HPKP)'' information is located in the ''Protocol Details'' section.
There is also a fast online HPKP-only check at [https://report-uri.io/home/pkp_analyse https://report-uri.io/home/pkp_analyse].


==== References ====
== TLS in der Praxis ==
* OWASP: Certificate and Public Key Pinning: [https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning]
TLS-Verschlüsselung wird gegenwärtig vor allem mit [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure HTTPS] eingesetzt
* HPKP Browser Compatibility List: [https://caniuse.com//#feat=publickeypinning https://caniuse.com/\#feat=publickeypinning]
* Die meisten aktuellen [https://de.wikipedia.org/wiki/Webbrowser Webbrowser] und [https://de.wikipedia.org/wiki/Webserver Webserver] bevorzugen TLS 1.3 und TLS 1.2
* RFC 7469:Public Key Pinning Extension for HTTP - Examples: [https://tools.ietf.org/html/rfc7469/#section-2.1.5 https://tools.ietf.org/html/rfc7469\#section-2.1.5]
* Die älteren Versionen TLS 1.1 und TLS 1.0 werden nicht mehr unterstützt
* In aktuellen Browsern ist SSLv3 und SSLv2 deaktiviert, da diese Protokollversion eine Reihe von Sicherheitslücken, unter anderem des [https://de.wikipedia.org/wiki/Poodle Poodle-Angriffs] aufweist


; TLS 1.3
Die Weiterentwicklung TLS 1.3 wird von allen nennenswert verbreiteten Browsern auf Desktops und Smartphones unterstützt
, TLS 1.2 wird von 98,7 Prozent aller Browserinstallationen unterstützt; Ausnahmen sind mehrere Jahre alte Versionen (Stand 02/2022)


= Links =
Das [https://de.wikipedia.org/wiki/Bundesamt_f%C3%BCr_Sicherheit_in_der_Informationstechnik Deutsche Bundesamt für Sicherheit in der Informationstechnik] empfiehlt bei der Verwendung von TLS die Versionen 1.2 und 1.3. [https://de.wikipedia.org/wiki/Cipher_Suite Cipher Suiten] mit [https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Perfect Forward Secrecy] werden bevorzugt empfohlen
== Intern ==
== Weblinks ==
# https://www.ssllabs.com/ssltest/
# https://certbot.eff.org/lets-encrypt/debianbuster-apache
# https://ssl-config.mozilla.org/


[[Kategorie:Verschlüsselung]]
Seit einiger Zeit nutzen immer mehr Webseitenbetreiber [https://de.wikipedia.org/wiki/Extended-Validation-Zertifikat Extended-Validation-TLS-Zertifikate] (EV-TLS-Zertifikat)
* In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wechsel mit der [https://de.wikipedia.org/wiki/Zertifizierungsstelle_(Digitale_Zertifikate) Zertifizierungsstelle] eingeblendet werden
* Zudem wird je nach verwendetem Browser und/oder Add-on die Adresszeile (teilweise) grün eingefärbt
* Internetnutzer sollen so schneller erkennen, ob die besuchte Webseite echt ist, und besser vor [https://de.wikipedia.org/wiki/Phishing Phishingversuchen] geschützt werden
* EV-TLS-Zertifikate bieten in technischer Sicht keinen erweiterten Schutz, die Verschlüsselung und deren Stärke ist identisch
* Nur der Inhaber wird dabei besser und aufwändiger verifiziert
* Seit 2019 werden diese Zertifikate in den Browsern nicht mehr prominent hervorgehoben, weil der erwartete Sicherheitsgewinn für den Endbenutzer ausblieb
 
Seit Januar 2017 markiert der Web-Browser Chrome Internetseiten als unsicher, die Informationen sammeln, ohne dabei HTTPS zu nutzen
* Das wird voraussichtlich zu einem signifikanten Anstieg des Einsatzes von HTTPS führen
* Im Februar 2017 war HTTPS bei 2,57 % aller registrierten deutschen Internet-Domains
 
sowie bei 3,70 % der österreichischen Domains
und 9,71 % der Schweizer Domains aktiviert
* Eine Untersuchung von rund 40.000 Webseiten klein- und mittelständischer Unternehmen in Baden-Württemberg durch den Landesbeauftragten für den Datenschutz und die Informationsfreiheit Baden-Württemberg hat ergeben, dass rund 7 % der untersuchten Webseiten über HTTPS angeboten werden
* Bei jenen Webseiten, die über HTTPS angeboten werden, ist die serverseitige Unterstützung für TLS 1.0 noch sehr weit verbreitet (99 %)
 
 
TLS ist ohne eine zertifikatsbasierte Authentifizierung anfällig für [https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff Man-in-the-Middle-Angriffe]: Ist der Man-in-the-Middle vor der Übergabe des Schlüssels aktiv, kann er beiden Seiten seine Schlüssel vorgaukeln und so den gesamten Datenverkehr im Klartext aufzeichnen und unbemerkt manipulieren
* Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt
 
Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich dieses Risiko jedoch weitgehend beseitigen
 
In Verbindung mit einem [https://de.wikipedia.org/wiki/Virtual_Hosting#IP_oder_namensbasiertes_Virtual_Hosting ''virtuellen Server''], zum Beispiel mit [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] (etwa beim [https://de.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] über den ''VHost''-Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus [https://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] und [https://de.wikipedia.org/wiki/Port_(Netzwerkadresse) Port] nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden
* Dieses Problem wurde mit der TLS-Erweiterung [https://de.wikipedia.org/wiki/Server_Name_Indication Server Name Indication] (SNI) im Juni 2003 durch den <nowiki>RFC&nbsp;3546</nowiki> behoben
* Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet
* Die ursprüngliche Erweiterung wurde für TLS 1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1, Version 1.2 und 1.3 entsprechend der Empfehlung umgesetzt
* In der Version 1.3 wird zusätzlich auch versucht, die SNI zu verschlüsseln, um mitzulesenden Parteien nicht zu ermöglichen, trotz verschlüsselter Verbindung Informationen über den Zielserver preiszugeben
* Das muss jedoch vom Browser unterstützt, im [https://de.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] ein Schlüssel hinterlegt und verschlüsseltes DNS genutzt werden
 
Im [https://de.wikipedia.org/wiki/Tor_(Netzwerk) Tor-Netzwerk] sind TLS-Zertifikate für Verbindungen in das Internet von besonderer Bedeutung, da ein Abhören einer unverschlüsselten Verbindung mittels [https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff Man-in-the-Middle-Angriff] dort durch den Rechner, der die Verbindung in das Internet herstellt (bezeichnet als „exit&nbsp;node“), sehr einfach möglich wäre
* Da eine Verbindung zwischen zwei Endpunkten im Tor-Netzwerks jedoch verschlüsselt ist, kann die verschlüsselte Übertragung von Daten innerhalb des Netzwerks nachrangig betrachtet werden, sofern man dem [https://de.wikipedia.org/wiki/Routing Routing] der Verbindungen vertraut
* Hier liegt das Hauptmerkmal der TLS-Verschlüsselung in der Authentizität der Gegenseite
 
Neben [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure HTTPS] als verschlüsselte Variante von [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] sind weitere bekannte Anwendungsfälle für TLS beispielsweise:
 
* [https://de.wikipedia.org/wiki/POP3S POP3S] für [https://de.wikipedia.org/wiki/Post_Office_Protocol POP3]
* [https://de.wikipedia.org/wiki/SMTPS SMTPS] für [https://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol SMTP]
* NNTPS für [https://de.wikipedia.org/wiki/Network_News_Transfer_Protocol NNTP]
* [https://de.wikipedia.org/wiki/Session_Initiation_Protocol#Verschl%C3%BCsselung_und_Sicherheit SIPS] für [https://de.wikipedia.org/wiki/Session_Initiation_Protocol SIP]
* [https://de.wikipedia.org/wiki/Internet_Message_Access_Protocol#IMAPS IMAPS] für [https://de.wikipedia.org/wiki/Internet_Message_Access_Protocol IMAP]
* [https://de.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol#Verschl%C3%BCsselung XMPPS] für [https://de.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol XMPP]
* [https://de.wikipedia.org/wiki/Internet_Relay_Chat#Verschl%C3%BCsselung IRCS] für [https://de.wikipedia.org/wiki/Internet_Relay_Chat IRC]
* LDAPS für [https://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol LDAP]
* [https://de.wikipedia.org/wiki/Multi-purpose_Business_Security_over_IP MBS/IP]-TLS
* [https://de.wikipedia.org/wiki/FTPS FTPS] für [https://de.wikipedia.org/wiki/File_Transfer_Protocol FTP]
* [https://de.wikipedia.org/wiki/Extensible_Authentication_Protocol EAP]-TLS
* [https://de.wikipedia.org/wiki/Tn3270 TN3270]-TLS
* [https://de.wikipedia.org/wiki/OpenVPN OpenVPN]
* [https://de.wikipedia.org/wiki/DNS_over_TLS DNS over TLS], [https://de.wikipedia.org/wiki/DNS_over_HTTPS DNS over HTTPS] und [https://de.wikipedia.org/wiki/DNS_over_QUIC DNS over QUIC] um DNS Abfragen durch TLS zu tunneln
 
Auch Verbindungen zu Datenbanksystemen können über TLS abgesichert werden
* Dabei werden die Identität des Servers oder auch des Clients geprüft und die gesamte Kommunikation verschlüsselt
 
=== Versionen ===
{| class="wikitable big options col1center"
! Version !! Erscheinungsjahr !!Bemerkungen
|-
| SSL 1.0 || 1994 ||
|-
| SSL 2.0 || 1995 || seit März 2011 überholt
|-
| SSL 3.0 || 1996 || |seit Juni 2015 überholt
|-
| TLS 1.0 || 1999 || seit März 2021 überholt
|-
| TLS 1.1 || 2006 || seit März 2021 überholt
|-
| TLS 1.2 || 2008 ||
|-
| TLS 1.3 || 2018 || RFC&nbsp;8446, enthält auch neue Anforderungen für TLS 1.2
|}
 
=== Geschichte ===
[[Transport Layer Security/Geschichte]]
 
== Funktionsweise ==
[[Transport Layer Security/Funktionsweise]]
 
== Sicherheit ==
[[TLS/Sicherheit]]
 
<noinclude>
 
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
----
* [[IPsec]]
 
==== Links ====
===== Weblinks =====
# https://de.wikipedia.org/wiki/Transport_Layer_Security
 
[[Kategorie:TLS]]
</noinclude>

Aktuelle Version vom 14. November 2024, 13:00 Uhr

Transport Layer Security (TLS) - Transportschichtsicherheit

Beschreibung

TLS im TCP/IP-Protokollstapel
Anwendung
 HTTPS IMAPS POP3S SMTPS …
TLS
Transport TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus 		Token
Ring 		FDDI …

Transport Layer Security (TLS, für „Transportschichtsicherheit“)

Hauptkomponenten

TLS besteht aus den beiden Hauptkomponenten TLS Handshake und TLS Record

  • Im TLS Handshake findet ein sicherer Schlüsselaustausch und eine Authentifizierung statt
  • TLS Record verwendet dann den im TLS Handshake ausgehandelten symmetrischen Schlüssel für eine sichere Datenübertragung – die Daten werden verschlüsselt und mit einem MAC gegen Veränderungen geschützt übertragen
Schlüsselaustausch

Für den Schlüsselaustausch sind in den älteren TLS-Versionen verschiedene Algorithmen mit unterschiedlichen Sicherheitsgarantien im Einsatz

Vor- und Nachteile

Der Vorteil des TLS-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des TLS-Protokolls zu implementieren

  • Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet

Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist

  • Die Verschlüsselung selbst beansprucht je nach verwendetem Algorithmus nur wenig Rechenzeit

Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf PPTP-Ebene) kaum durch Kompression zu verdichten

TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen

  • Es sind Szenarien in serviceorientierten Architekturen denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird
  • Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann
  • Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann

Implementierungen

Zu den bekanntesten Programmbibliotheken, die Transport Layer Security implementieren, gehören:

TLS in der Praxis

TLS-Verschlüsselung wird gegenwärtig vor allem mit HTTPS eingesetzt

  • Die meisten aktuellen Webbrowser und Webserver bevorzugen TLS 1.3 und TLS 1.2
  • Die älteren Versionen TLS 1.1 und TLS 1.0 werden nicht mehr unterstützt
  • In aktuellen Browsern ist SSLv3 und SSLv2 deaktiviert, da diese Protokollversion eine Reihe von Sicherheitslücken, unter anderem des Poodle-Angriffs aufweist
TLS 1.3

Die Weiterentwicklung TLS 1.3 wird von allen nennenswert verbreiteten Browsern auf Desktops und Smartphones unterstützt , TLS 1.2 wird von 98,7 Prozent aller Browserinstallationen unterstützt; Ausnahmen sind mehrere Jahre alte Versionen (Stand 02/2022)

Das Deutsche Bundesamt für Sicherheit in der Informationstechnik empfiehlt bei der Verwendung von TLS die Versionen 1.2 und 1.3. Cipher Suiten mit Perfect Forward Secrecy werden bevorzugt empfohlen

Seit einiger Zeit nutzen immer mehr Webseitenbetreiber Extended-Validation-TLS-Zertifikate (EV-TLS-Zertifikat)

  • In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wechsel mit der Zertifizierungsstelle eingeblendet werden
  • Zudem wird je nach verwendetem Browser und/oder Add-on die Adresszeile (teilweise) grün eingefärbt
  • Internetnutzer sollen so schneller erkennen, ob die besuchte Webseite echt ist, und besser vor Phishingversuchen geschützt werden
  • EV-TLS-Zertifikate bieten in technischer Sicht keinen erweiterten Schutz, die Verschlüsselung und deren Stärke ist identisch
  • Nur der Inhaber wird dabei besser und aufwändiger verifiziert
  • Seit 2019 werden diese Zertifikate in den Browsern nicht mehr prominent hervorgehoben, weil der erwartete Sicherheitsgewinn für den Endbenutzer ausblieb

Seit Januar 2017 markiert der Web-Browser Chrome Internetseiten als unsicher, die Informationen sammeln, ohne dabei HTTPS zu nutzen

  • Das wird voraussichtlich zu einem signifikanten Anstieg des Einsatzes von HTTPS führen
  • Im Februar 2017 war HTTPS bei 2,57 % aller registrierten deutschen Internet-Domains

sowie bei 3,70 % der österreichischen Domains und 9,71 % der Schweizer Domains aktiviert

  • Eine Untersuchung von rund 40.000 Webseiten klein- und mittelständischer Unternehmen in Baden-Württemberg durch den Landesbeauftragten für den Datenschutz und die Informationsfreiheit Baden-Württemberg hat ergeben, dass rund 7 % der untersuchten Webseiten über HTTPS angeboten werden
  • Bei jenen Webseiten, die über HTTPS angeboten werden, ist die serverseitige Unterstützung für TLS 1.0 noch sehr weit verbreitet (99 %)


TLS ist ohne eine zertifikatsbasierte Authentifizierung anfällig für Man-in-the-Middle-Angriffe: Ist der Man-in-the-Middle vor der Übergabe des Schlüssels aktiv, kann er beiden Seiten seine Schlüssel vorgaukeln und so den gesamten Datenverkehr im Klartext aufzeichnen und unbemerkt manipulieren

  • Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt

Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich dieses Risiko jedoch weitgehend beseitigen

In Verbindung mit einem virtuellen Server, zum Beispiel mit HTTP (etwa beim Apache HTTP Server über den VHost-Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus IP-Adresse und Port nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden

  • Dieses Problem wurde mit der TLS-Erweiterung Server Name Indication (SNI) im Juni 2003 durch den RFC 3546 behoben
  • Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet
  • Die ursprüngliche Erweiterung wurde für TLS 1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1, Version 1.2 und 1.3 entsprechend der Empfehlung umgesetzt
  • In der Version 1.3 wird zusätzlich auch versucht, die SNI zu verschlüsseln, um mitzulesenden Parteien nicht zu ermöglichen, trotz verschlüsselter Verbindung Informationen über den Zielserver preiszugeben
  • Das muss jedoch vom Browser unterstützt, im Domain Name System (DNS) ein Schlüssel hinterlegt und verschlüsseltes DNS genutzt werden

Im Tor-Netzwerk sind TLS-Zertifikate für Verbindungen in das Internet von besonderer Bedeutung, da ein Abhören einer unverschlüsselten Verbindung mittels Man-in-the-Middle-Angriff dort durch den Rechner, der die Verbindung in das Internet herstellt (bezeichnet als „exit node“), sehr einfach möglich wäre

  • Da eine Verbindung zwischen zwei Endpunkten im Tor-Netzwerks jedoch verschlüsselt ist, kann die verschlüsselte Übertragung von Daten innerhalb des Netzwerks nachrangig betrachtet werden, sofern man dem Routing der Verbindungen vertraut
  • Hier liegt das Hauptmerkmal der TLS-Verschlüsselung in der Authentizität der Gegenseite

Neben HTTPS als verschlüsselte Variante von HTTP sind weitere bekannte Anwendungsfälle für TLS beispielsweise:

Auch Verbindungen zu Datenbanksystemen können über TLS abgesichert werden

  • Dabei werden die Identität des Servers oder auch des Clients geprüft und die gesamte Kommunikation verschlüsselt

Versionen

Version Erscheinungsjahr Bemerkungen
SSL 1.0 1994
SSL 2.0 1995 seit März 2011 überholt
SSL 3.0 1996 seit Juni 2015 überholt
TLS 1.0 1999 seit März 2021 überholt
TLS 1.1 2006 seit März 2021 überholt
TLS 1.2 2008
TLS 1.3 2018 RFC 8446, enthält auch neue Anforderungen für TLS 1.2

Geschichte

Transport Layer Security/Geschichte

Funktionsweise

Transport Layer Security/Funktionsweise

Sicherheit

TLS/Sicherheit


Anhang

Siehe auch

Links

Weblinks
  1. https://de.wikipedia.org/wiki/Transport_Layer_Security
Abgerufen von „https://wiki.foxtom.de/index.php?title=Transport_Layer_Security&oldid=115490“