Sind HTTPS-URLs verschlüsselt?

1020

Werden alle URLs bei Verwendung der TLS / SSL (HTTPS) -Verschlüsselung verschlüsselt? Ich würde gerne wissen, weil ich möchte, dass alle URL-Daten bei Verwendung von TLS / SSL (HTTPS) ausgeblendet werden.

Wenn TLS / SSL Ihnen eine vollständige URL-Verschlüsselung bietet, muss ich mir keine Sorgen machen, vertrauliche Informationen vor URLs zu verbergen.

ssl  https  httprequest 
— Daniel Kivatinos
quelle
76
Es ist wahrscheinlich eine schlechte Idee, vertrauliche Daten in die URL aufzunehmen. Es wird auch in der Adresse des Browsers schlecht angezeigt, erinnerst du dich? Menschen mögen es nicht, wenn ihr Passwort für jeden sichtbar ist, der zufällig auf den Bildschirm schaut. Warum müssen Sie Ihrer Meinung nach vertrauliche Daten in die URL einfügen?
— Jalf
43
URLs werden auch im Browserverlauf und in den Serverprotokollen gespeichert. Wenn ich meinen Namen und mein Kennwort irgendwo speichern möchte, befinden sie sich nicht an diesen beiden Stellen.
— Piskvor verließ das Gebäude am
47
Angenommen, ich besuche https://somewhere_i_trust/ways_to_protest_against_the_government/. Dann enthält die URL vertrauliche Daten, nämlich den Vorschlag, gegen meine Regierung zu protestieren.
— Steve Jessop
42
Ich habe mir diese Frage gestellt, als ich eine HTTP-Anfrage von einer nativen (nicht browserbasierten) App gestellt habe. Ich vermute, dass dies Entwickler mobiler Apps interessieren könnte. In diesem Fall sind die obigen Kommentare (obwohl sie wahr sind) irrelevant (keine URL sichtbar, kein Browserverlauf), was die Antwort nach meinem Verständnis einfach macht: "Ja, sie ist verschlüsselt".
— DannyA
23
Für diejenigen, die denken, wenn Sie einmal HTTPS sind, weiß niemand, wohin Sie gehen, lesen Sie zuerst Folgendes : Der Hostname des Servers (z. B. example.com) wird aufgrund von SNI immer noch durchgesickert . Dies hat absolut nichts mit DNS zu tun und das Leck tritt auch dann auf, wenn Sie kein DNS oder verschlüsseltes DNS verwenden.
— Pacerier

Antworten:

913

Ja, die SSL-Verbindung besteht zwischen der TCP-Schicht und der HTTP-Schicht. Der Client und der Server stellen zuerst eine sichere verschlüsselte TCP-Verbindung her (über das SSL / TLS-Protokoll), und dann sendet der Client die HTTP-Anforderung (GET, POST, DELETE ...) über diese verschlüsselte TCP-Verbindung.

— Marc Novakowski
quelle
98
Es ist immer noch erwähnenswert, was @Jalf im Kommentar zur Frage selbst erwähnt hat. URL-Daten werden auch im Verlauf des Browsers gespeichert, was langfristig unsicher sein kann.
— Michael Ekstrand
20
Nicht nur GET oder POST. Kann auch DELETE, PUT, HEAD oder TRACE sein.
4
Ja, es könnte ein Sicherheitsproblem für den Verlauf eines Browsers sein. Aber in meinem Fall benutze ich keinen Browser (auch im ursprünglichen Beitrag wurde kein Browser erwähnt). Verwenden eines benutzerdefinierten https-Aufrufs hinter den Kulissen einer nativen App. Dies ist eine einfache Lösung, um sicherzustellen, dass die getrennte Verbindung Ihrer App sicher ist.
— Zingle-Dingle
28
Beachten Sie jedoch, dass die DNS-Auflösung der URL wahrscheinlich nicht verschlüsselt ist. Jemand, der Ihren Datenverkehr beschnüffelt, könnte wahrscheinlich immer noch die Domain sehen, auf die Sie zugreifen möchten.
— ChewToy
21
SNI unterbricht den 'Host'-Teil der SSL-Verschlüsselung von URLs. Sie können dies selbst mit Wireshark testen. Es gibt einen Selektor für SNI, oder Sie können Ihre SSL-Pakete einfach überprüfen, wenn Sie eine Verbindung zum Remote-Host herstellen.
— cmouse
654

Da niemand eine Kabelaufnahme bereitstellte, ist hier eine.
Der Servername (der Domänenteil der URL) wird im ClientHelloPaket im Klartext dargestellt .

Das Folgende zeigt eine Browseranforderung an:
https://i.stack.imgur.com/path/?some=parameters&go=here

ClientHello SNI Weitere Informationen zu TLS-Versionsfeldern finden Sie in dieser Antwort (es gibt drei davon - keine Versionen, Felder, die jeweils eine Versionsnummer enthalten!)

Von https://www.ietf.org/rfc/rfc3546.txt :

3.1. Anzeige des Servernamens

[TLS] bietet keinen Mechanismus für einen Client, um einem Server den Namen des Servers mitzuteilen, den er kontaktiert. Es kann wünschenswert sein, dass Clients diese Informationen bereitstellen, um sichere Verbindungen zu Servern zu ermöglichen, auf denen mehrere "virtuelle" Server an einer einzigen zugrunde liegenden Netzwerkadresse gehostet werden.

Um den Servernamen anzugeben, können Clients eine Erweiterung vom Typ "Servername" in das (erweiterte) Client-Hallo aufnehmen.


Zusamenfassend:

  • FQDN (der Domänenteil der URL) KANN übertragen werden in klar innerhalb derClientHello Pakets , wenn SNI Erweiterung verwendet wird

  • Der Rest der URL ( /path/?some=parameters&go=here) hat nichts damit zu ClientHellotun, da die Anforderungs-URL eine HTTP-Sache ist (OSI-Schicht 7), daher wird sie niemals in einem TLS-Handshake (Schicht 4 oder 5) angezeigt. Dies wird später in einer GET /path/?some=parameters&go=here HTTP/1.1HTTP-Anfrage geschehen , nachdem der sichere TLS-Kanal eingerichtet wurde.


ZUSAMMENFASSUNG

Der Domainname kann eindeutig übertragen werden (wenn die SNI-Erweiterung im TLS-Handshake verwendet wird), die URL (Pfad und Parameter) wird jedoch immer verschlüsselt.


MÄRZ 2019 UPDATE

Vielen Dank an carlin.scott , dass Sie dieses Thema angesprochen haben.

Die Nutzdaten in der SNI-Erweiterung können jetzt über diesen Entwurf eines RFC-Vorschlags verschlüsselt werden . Diese Funktion ist nur in TLS 1.3 verfügbar (als Option und es liegt an beiden Enden, sie zu implementieren), und es gibt keine Abwärtskompatibilität mit TLS 1.2 und darunter.

CloudFlare macht es und Sie können hier mehr über die Einbauten lesen - Wenn das Huhn vor das Ei kommen muss, wo legen Sie das Huhn hin?

In der Praxis bedeutet dies, dass der FQDN nicht mehr im Klartext übertragen wird (wie das Wireshark-Capture zeigt), sondern jetzt verschlüsselt ist.

HINWEIS: Dies betrifft mehr den Datenschutzaspekt als den Sicherheitsaspekt, da bei einer umgekehrten DNS-Suche der beabsichtigte Zielhost ohnehin angezeigt werden kann.

— evilSnobu
quelle
37
Perfekte Antwort mit vollständiger Erklärung von A bis Z. Ich liebe die Zusammenfassung. Machte meinen Tag @evilSnobu
— oscaroscar
4
Perfekte Antwort, Upvote! Berücksichtigen Sie dennoch den Client-Teil, da der Browserverlauf möglicherweise ein Leck ist. In Bezug auf die Transportschicht werden URL-Parameter jedoch verschlüsselt.
— Jens Kreidler
2
Möglicherweise möchten Sie diese Antwort mit der Tatsache aktualisieren, dass TLS 1.3 die SNI-Erweiterung verschlüsselt und das größte CDN genau das tut: blog.cloudflare.com/encrypted-sni Natürlich könnte ein Paket-Sniffer auch eine Reverse-DNS-Suche durchführen die IP-Adressen, mit denen Sie eine Verbindung herstellen.
— carlin.scott
@evilSnobu, aber Benutzername: Passwort Teil des Benutzernamens: Passwort@domain.com ist verschlüsselt, oder? Es ist also sicher, vertrauliche Daten mithilfe von https in einer URL zu übergeben.
— Maksim Shamihulau
1
Sie werden auf dem Kabel (während des Transports) verschlüsselt, aber wenn eines der Endgeräte (Benutzer oder Server) die URL in einer Nur-Text-Datei protokolliert und die Anmeldeinformationen nicht bereinigt ... ist dies eine andere Konversation.
— EvilSnobu
159

Wie die anderen Antworten bereits gezeigt haben, sind https "URLs" tatsächlich verschlüsselt. Ihre DNS-Anfrage / Antwort beim Auflösen des Domainnamens ist jedoch wahrscheinlich nicht. Wenn Sie einen Browser verwenden, werden möglicherweise auch Ihre URLs aufgezeichnet.

— Zach Scrivena
quelle
21
Die URL-Aufzeichnung ist wichtig, da es Javascript-Hacks gibt, mit denen eine völlig unabhängige Site testen kann, ob sich eine bestimmte URL in Ihrem Verlauf befindet oder nicht. Sie können eine URL nicht erraten, indem Sie eine längere zufällige Zeichenfolge einfügen. Wenn es sich jedoch um eine öffentliche URL handelt, kann der Angreifer feststellen, dass sie besucht wurde, und wenn sie ein kurzes Geheimnis enthält, kann ein Angreifer dies brutal erzwingen mit angemessener Geschwindigkeit.
— Steve Jessop
8
@SteveJessop, bitte geben Sie einen Link zu "Javascript-Hacks, mit denen eine völlig unabhängige Site testen kann, ob eine bestimmte URL in Ihrem Verlauf enthalten ist oder nicht"
— Pacerier
6
@ Pacerier: Hacks Datum natürlich, aber worüber ich damals sprach, waren Dinge wie stackoverflow.com/questions/2394890/… . Es war eine große Sache im Jahr 2010, dass diese Probleme untersucht und die Angriffe verfeinert wurden, aber ich verfolge sie im Moment nicht wirklich.
— Steve Jessop
2
@ Pacerier: weitere Beispiele: webdevwonders.com/… , webdevwonders.com/…
— Steve Jessop
1
Sie können OpenDNS mit seinem verschlüsselten DNS-Dienst verwenden. Ich benutze es auf meinem Mac, aber ich habe festgestellt, dass die Windows-Version nicht richtig funktioniert. Das ist allerdings schon eine Weile her, also könnte es jetzt in Ordnung sein. Für Linux noch nichts. opendns.com/about/innovations/dnscrypt
— SPRBRN
101

Die gesamte Anfrage und Antwort wird einschließlich der URL verschlüsselt.

Beachten Sie, dass bei Verwendung eines HTTP-Proxys die Adresse (Domäne) des Zielservers bekannt ist, der angeforderte Pfad auf diesem Server jedoch nicht bekannt ist (dh Anforderung und Antwort werden immer verschlüsselt).

— Peter Štibraný
quelle
1
Die Gesamtheit der Anfrage. Der Hostname wird im Klartext gesendet. Alles andere ist verschlüsselt.
— Sam Sirry
98

Ich stimme den vorherigen Antworten zu:

Um explizit zu sein:

Mit TLS der erste Teil der URL ( https://www.example.com/ ) beim Aufbau der Verbindung weiterhin sichtbar. Der zweite Teil (/ herearemygetparameters / 1/2/3/4) ist durch TLS geschützt.

Es gibt jedoch eine Reihe von Gründen, warum Sie keine Parameter in die GET-Anforderung einfügen sollten.

Erstens, wie bereits von anderen erwähnt: - Leckage durch die Adressleiste des Browsers - Leckage durch den Verlauf

Darüber hinaus tritt über den http-Referer eine URL aus: Der Benutzer sieht Site A auf TLS und klickt dann auf einen Link zu Site B. Wenn sich beide Sites in TLS befinden, enthält die Anforderung an Site B die vollständige URL von Site A in der Referer-Parameter der Anfrage. Und der Administrator von Site B kann es aus den Protokolldateien von Server B abrufen.)

— Tobias
quelle
3
@EJP Du hast nicht verstanden, was Tobias sagt. Er sagt, wenn Sie auf einen Link auf Site A klicken, der Sie zu Site B führt, erhält Site B die Referrer-URL. Wenn Sie sich beispielsweise auf siteA.com?u=username&pw=123123 befinden , erhält siteB.com (das auf der Seite von siteA.com verlinkt ist) " siteA.com?u=username&pw=123123 " als Referenz URL, die vom Browser innerhalb des HTTPS an siteB.com gesendet wird. Wenn das stimmt, ist das sehr schlecht. Ist das wahr, Tobias?
— Trusktr
9
@EJP, die Domain ist aufgrund der SNI sichtbar, die alle modernen Webbrowser verwenden. Sehen Sie sich auch dieses Diagramm aus dem EFF an, das zeigt, dass jeder die Domain der Site sehen kann, die Sie besuchen. Hier geht es nicht um die Sichtbarkeit des Browsers. Es geht darum, was für Lauscher sichtbar ist.
— Buge
10
@trusktr: Browser sollten keinen Referer-Header von HTTPS-Seiten senden. Dies ist Teil der HTTP-Spezifikation .
— Martin Geisler
8
@ MartinGeisler, Schlüsselwort ist "sollte". Browser interessieren sich nicht viel für "sollte" (im Gegensatz zu "muss"). Über Ihren eigenen Link: "Es wird dringend empfohlen, dass der Benutzer auswählen kann, ob das Feld" Referer "gesendet werden soll oder nicht. Beispielsweise könnte ein Browser-Client einen Kippschalter zum offenen / anonymen Surfen haben, der das Senden von aktiviert bzw. deaktiviert Referer und From Information " . Ops, genau das hat Chrome getan. Außer Chrome leckt der Referrer auch dann, wenn Sie sich im Inkognito-Modus befinden .
— Pacerier
48

Eine Ergänzung zu der hilfreichen Antwort von Marc Novakowski: Die URL wird in den Protokollen auf dem Server gespeichert (z. B. in / etc / httpd / logs / ssl_access_log). Wenn Sie also nicht möchten, dass der Server die Informationen länger verwaltet Begriff, nicht in die URL einfügen.

— Rhodri Cusack
quelle
34

Ja und nein.

Der Serveradressenteil wird NICHT verschlüsselt, da er zum Einrichten der Verbindung verwendet wird.

Dies kann sich in Zukunft mit verschlüsseltem SNI und DNS ändern, aber ab 2018 werden beide Technologien nicht mehr häufig verwendet.

Der Pfad, die Abfragezeichenfolge usw. werden verschlüsselt.

Hinweis: Bei GET-Anforderungen kann der Benutzer die URL weiterhin ausschneiden und aus der Positionsleiste einfügen. Möglicherweise möchten Sie dort keine vertraulichen Informationen einfügen, die von jedem gesehen werden können, der auf den Bildschirm schaut.

— Seifenkiste
quelle
8
Möchte dies +1, aber ich finde das "Ja und Nein" irreführend - Sie sollten dies ändern, um nur darauf hinzuweisen, dass der Servername mit DNS ohne Verschlüsselung aufgelöst wird.
— Lawrence Dol
7
Nach meinem Verständnis verwendet das OP das Wort URL im richtigen Sinne. Ich denke, diese Antwort ist irreführender, da sie nicht eindeutig den Unterschied zwischen dem Hostnamen in der URL und dem Hostnamen in der DNS-Auflösung ausmacht.
— Guillaume
4
Die URL ist verschlüsselt. Jeder Aspekt der HTTP-Transaktion ist verschlüsselt. Nicht nur "alles andere". Zeitraum. -1.
— Marquis von Lorne
4
@EJP aber der DNS - Lookup macht Gebrauch , was an einem Punkt Teil der URL ist, so auf die nicht-technische Person, wird die gesamte URL nicht verschlüsselt. Die nicht technische Person, die Google.com lediglich zum Nachschlagen nicht technischer Dinge verwendet, weiß nicht, wo sich die Daten letztendlich befinden oder wie sie behandelt werden. Die Domain, die Teil der URL ist, die der Benutzer besucht, ist nicht zu 100% verschlüsselt, da ich als Angreifer feststellen kann, welche Site er besucht. Nur der / -Pfad einer URL wird dem Laien von Natur aus verschlüsselt (egal wie).
— Trusktr
6
@EJP, @ trusktr, @ Lawrence, @ Guillaume. Sie alle irren sich. Dies hat nichts mit DNS zu tun. SNI " Senden Sie den Namen der virtuellen Domäne als Teil der TLS-Aushandlung ". Selbst wenn Sie kein DNS verwenden oder wenn Ihr DNS verschlüsselt ist, kann ein Sniffer den Hostnamen Ihrer Anforderungen weiterhin sehen .
— Pacerier
9

Ein Drittanbieter, der den Datenverkehr überwacht, kann die besuchte Seite möglicherweise auch ermitteln, indem er Ihren Datenverkehr untersucht und mit dem Datenverkehr vergleicht, den ein anderer Benutzer beim Besuch der Website hat. Wenn beispielsweise nur zwei Seiten auf einer Site vorhanden sind, von denen eine viel größer als die andere ist, zeigt ein Vergleich der Größe der Datenübertragung, welche Seite Sie besucht haben. Es gibt Möglichkeiten, wie dies vor Drittanbietern verborgen werden kann, aber sie sind kein normales Server- oder Browserverhalten. Siehe zum Beispiel dieses Dokument von SciRate unter https://scirate.com/arxiv/1403.0297 .

Im Allgemeinen sind andere Antworten richtig, obwohl dieses Papier praktisch zeigt, dass besuchte Seiten (dh URL) sehr effektiv bestimmt werden können.

— pbhj
quelle
Das wäre wirklich nur auf sehr kleinen Websites möglich, und in diesen Fällen wäre das Thema / der Ton / die Art der Website wahrscheinlich auf jeder Seite ungefähr gleich.
— Cameron
5
Aus dem Zitat, das ich gegeben habe: "Wir präsentieren einen Verkehrsanalyseangriff gegen über 6000 Webseiten, der die HTTPS-Bereitstellung von 10 weit verbreiteten, branchenführenden Websites in Bereichen wie Gesundheitswesen, Finanzen, Rechtsberatung und Streaming-Video umfasst. Unser Angriff identifiziert einzelne Seiten in die gleiche Website mit 89% Genauigkeit [...] ". Ihre Schlussfolgerung zur Machbarkeit scheint falsch zu sein.
— pbhj
2
Für alle, die mehr über diese Art von Sicherheitsanfälligkeit erfahren möchten, werden diese Arten von Angriffen im Allgemeinen als Seitenkanalangriffe bezeichnet .
— Dan Bechard
7

Sie können sich auch nicht immer auf die Privatsphäre der vollständigen URL verlassen. Beispielsweise werden gelieferte Geräte wie Ihr Unternehmens-PC, wie dies manchmal in Unternehmensnetzwerken der Fall ist, mit einem zusätzlichen "vertrauenswürdigen" Stammzertifikat konfiguriert, sodass Ihr Browser einer Proxy-Überprüfung (Man-in-the-Middle) des https-Verkehrs stillschweigend vertrauen kann . Dies bedeutet, dass die vollständige URL zur Überprüfung verfügbar gemacht wird. Dies wird normalerweise in einem Protokoll gespeichert.

Darüber hinaus werden Ihre Passwörter auch angezeigt und wahrscheinlich protokolliert. Dies ist ein weiterer Grund, einmalige Passwörter zu verwenden oder Ihre Passwörter häufig zu ändern.

Schließlich wird der Anforderungs- und Antwortinhalt auch angezeigt, wenn er nicht anderweitig verschlüsselt ist.

Ein Beispiel für den Inspektionsaufbau wird hier von Checkpoint beschrieben . Auf diese Weise kann auch ein "Internetcafé" im alten Stil mit den mitgelieferten PCs eingerichtet werden.

— Don Gillis
quelle
6

Link zu meiner Antwort auf eine doppelte Frage . Die URL ist nicht nur im Browserverlauf verfügbar, die serverseitigen Protokolle werden auch als HTTP-Referer-Header gesendet. Wenn Sie Inhalte von Drittanbietern verwenden, wird die URL Quellen ausgesetzt, die außerhalb Ihrer Kontrolle liegen.

— JoshBerke
quelle
Vorausgesetzt, Ihre Anrufe von Drittanbietern sind ebenfalls HTTPS, obwohl dies kein Problem ist, oder?
— Liam
3
Es würde mit dem Zertifikat eines Drittanbieters verschlüsselt, damit sie die URL sehen könnten
— JoshBerke
5

Es ist jetzt 2019 und die TLS v1.3 wurde veröffentlicht. Laut Cloudflare kann das SNI dank TLS v1.3 verschlüsselt werden. Also sagte ich mir großartig! Mal sehen, wie es in den TCP-Paketen von cloudflare.com aussieht. Also habe ich ein "Client-Hallo" -Handshake-Paket von einer Antwort des Cloudflare-Servers mit Google Chrome als Browser und Wireshark als Paket-Sniffer abgefangen. Ich kann den Servernamen immer noch im Klartext innerhalb des Client-Hallo-Pakets lesen.

Geben Sie hier die Bildbeschreibung ein

Achten Sie also darauf, was Sie lesen können, da dies immer noch keine anonyme Verbindung ist. Eine Middleware zwischen dem Client und dem Server kann jede Domäne protokollieren, die von einem Client angefordert wird.

Es sieht also so aus, als ob die Verschlüsselung des SNI zusätzliche Implementierungen erfordert, um mit TLSv1.3 zusammenzuarbeiten

Der folgende Artikel beschreibt die Verschlüsselung des von Cloudflare als Teil von TLSv1.3 bereitgestellten SNI. Alle HTTP-URLs von cloudflare.com sind jedoch im TCP-Paket unter TLS v1.3 im Klartext enthalten

[ https://blog.cloudflare.com/encrypted-sni/ weibliches [ 3]

— Nicolas Guérinet
quelle
"Das SNI kann verschlüsselt werden" - das ist der entscheidende Punkt. Überprüfen cloudflare.com/ssl/encrypted-sni mit aktuellen Google Chrome sagt : „Ihr Browser nicht die SNI verschlüsseln , wenn diese Seite zu besuchen.“ Tango braucht zwei ...
— Piskvor verließ das Gebäude
Offenbar aktuellen Firefox kann ESNI tun, aber es ist standardmäßig deaktiviert: Sie aktivieren müssen network.security.esni.enabled, Satz network.trr.mode2 (die zur Zeit Ihre DoH Resolver CloudFlare setzt), und starten Sie den Browser, (sic!) Dann wird ESNI verwendet - sofern dies von der Infrastruktur der Domäne unterstützt wird. Weitere Informationen finden Sie unter blog.mozilla.org/security/2018/10/18/… .
— Piskvor verließ das Gebäude
2

Obwohl es hier bereits einige gute Antworten gibt, konzentrieren sich die meisten auf die Browsernavigation. Ich schreibe dies im Jahr 2018 und wahrscheinlich möchte jemand etwas über die Sicherheit mobiler Apps wissen.

Wenn Sie bei mobilen Apps beide Enden der Anwendung (Server und App) steuern, sind Sie sicher , solange Sie HTTPS verwenden . iOS oder Android überprüfen das Zertifikat und mildern mögliche MiM-Angriffe (dies wäre die einzige Schwachstelle in all dem). Sie können vertrauliche Daten über HTTPS-Verbindungen senden, die während des Transports verschlüsselt werden . Nur Ihre App und der Server kennen alle Parameter, die über https gesendet werden.

Das einzige "Vielleicht" hier wäre, wenn Client oder Server mit schädlicher Software infiziert sind, die die Daten sehen kann, bevor sie in https eingeschlossen werden. Wenn jedoch jemand mit dieser Art von Software infiziert ist, hat er Zugriff auf die Daten, unabhängig davon, mit was Sie sie transportieren.

— Ricardo BRGWeb
quelle
1

Wenn Sie eine ReSTful-API erstellen, werden außerdem Probleme mit Browserlecks und http-Verweisen meistens behoben, da der Client möglicherweise kein Browser ist und möglicherweise keine Personen auf Links klicken.

In diesem Fall würde ich die Anmeldung bei oAuth2 empfehlen, um ein Inhaber-Token zu erhalten. In diesem Fall wären die einzigen vertraulichen Daten die anfänglichen Anmeldeinformationen ... die wahrscheinlich sowieso in einer Post-Anfrage enthalten sein sollten

— Chris Rutledge
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.