Sie sollten sich OSI-Schichten als Verpackung vorstellen.

Nehmen wir an, ich möchte Ihnen ein Glas schicken. Ich habe ein Originalpaket für Werbezwecke ausgewählt, um zu zeigen, wie schön mein Produkt ist und was Sie kaufen können, um Ihr "Glas" -Erlebnis zu verbessern. Das ist die oberste Ebene meines Protokolls.

Dann habe ich dieses Paket in eine Schachtel mit weichen Dingen gelegt, weil ich nicht möchte, dass es durch den Transport beschädigt wird. Dies ist eine zweite Schicht.

Dann legt meine Versandabteilung diese Schachtel in ein größeres Paket mit einem Etikett, das zu Ihnen nach Hause geliefert werden soll. Wieder eine weitere Schicht.

Dann legte der Transporter diese Kiste mit vielen anderen Kisten in einen LKW und wies den Fahrer an, zu einem anderen Lieferzentrum zu gehen, wieder zu einer anderen Schicht.

Für das, was wir wissen, muss der LKW-Fahrer nicht wissen:

• Wohin gehen die Kisten genau bei Ihnen zu Hause? Er muss nur Ihre Adresse kennen.
• welcher Schutz in den Kisten ist, muss er nur so sicher fahren, wie es in seinem Vertrag vorgeschrieben ist
• was genau in den Kisten ist

Lassen Sie uns Sagen Sie jetzt, dass ich meine Sendung vertraulich behandeln möchte. Denn ein neugieriger Fahrer könnte versuchen, die Pakete zu manipulieren, um zu wissen, was sich darin befindet, oder sie stehlen und weiterverkaufen.

Ich kann ein Protokoll verwenden, bei dem Ihr verpacktes, weich beschichtetes Glas auch in eine Metallbox mit einem Schließfach gegeben wird. Es schützt es vor Manipulationen durch den LKW-Fahrer, da er nicht hineinschauen oder die Ware mitnehmen kann. Es schützt nicht die unteren Schichten, er könnte immer noch den ganzen Bund in einen See werfen, dies ist Denial-of-Service. Außerdem ist es meinem Schließfach egal, was sich darin befindet. Es könnte dein Glas sein, es könnten Blumen sein oder es könnte leer sein. Es dient jedoch weiterhin dazu, zu vermeiden, dass andere Personen als Sie (und der Versender von c) wissen, was sich darin befindet.

Dies gilt auch für die Protokolle im OSI. Die unteren Schichten kümmern sich nicht darum, was in den oberen Schichten passiert. Dies bleibt einem anderen Agenten überlassen, um es zu dekodieren / zu verarbeiten.

Zur Verdeutlichung bearbeiten: Wenn wir "unverändert lassen" sagen, bedeutet dies nicht, dass die Informationen nicht verarbeitet werden. Insbesondere für SSL ist die Nutzlast der SSL-Schicht eine Verschlüsselung des Pakets der höheren Schicht. Wenn SSL jedoch auf der anderen Seite ausgeführt wird, wird das ursprüngliche Paket ohne Änderung entschlüsselt.

Während OSI nur ein Modell ist und die Ebenen in Wirklichkeit unscharf oder nicht vorhanden sein können, besteht das Konzept der Ebenenprotokolle speziell darin, eine Änderung in einer bestimmten Ebene zuzulassen, um die darüber und darunter liegenden Ebenen in Ruhe zu lassen.

Als Beispiel:

• Physisch - kümmert sich ein Basispaket darum, ob es über Kupfer, Glasfaser oder drahtlos übertragen wird? Es könnte irgendwann auf seiner Reise über alle drei reisen. Sie möchten http nicht für jedes dieser physischen Medien in bestimmten Varianten neu schreiben müssen, also tun Sie es einmal.

Die wichtigsten Elemente sind also, wie jede Ebene mit den benachbarten verbunden ist

@ M'vys Metapher, einen physischen Gegenstand zu transportieren, ist hier sehr angemessen.

TCP bietet Anwendungen eine Stream-Schnittstelle. Es gibt einige Ausnahmen, in denen die Details durchgesickert sind, aber im Allgemeinen wird ein TCP-Socket geöffnet, und dann sendet jede Seite eine Reihe von Bytes an die andere. Diese Bytes werden intakt und in der richtigen Reihenfolge geliefert, bis das entfernte Ende die Verbindung schließt (über die Sie informiert werden). Anwendungen müssen nur die Stream-Schnittstelle kennen. Sie müssen nicht über die Details der zugrunde liegenden Netzwerkhardware Bescheid wissen, sie müssen nicht über Überlastungskontrolle, Fenstergrößen, erneute Übertragung von Paketen oder sogar darüber Bescheid wissen, dass Pakete vorhanden sind.

TLS befindet sich auf TCP und bietet Authentifizierungs- und Verschlüsselungsdienste. Außerdem bietet Anwendungen eine Stream-Schnittstelle. Unter der Haube gibt es eine Reihe zusätzlicher Dinge, eine Reihe neuer potenzieller Fehlerbedingungen und eine Reihe neuer Metadaten, nach denen eine Anwendung einen Socket abfragt (z. B. Informationen über das Remote-Zertifikat und sein Problem), aber die Grundlegende Vorgänge sind dieselben: Stellen Sie eine Verbindung zu einer bestimmten Adresse her, senden Sie Bytes, empfangen Sie Bytes, schließen Sie die Verbindung und werden Sie über ein Remote-Schließen informiert.

Der Punkt dabei ist, dass jedes Protokoll auf Anwendungsebene, das auf den von TCP bereitgestellten Streams ausgeführt werden kann, auch auf den von SSL bereitgestellten Streams ausgeführt werden kann, ohne dass grundlegende Änderungen an der vorgenommen werden müssen Anwendung selbst. In Fällen, in denen es nicht als wichtig erachtet wird, dass die Anwendung Informationen über die verwendete Verschlüsselung oder das Zertifikat der Gegenstelle oder eines davon erhält, können Sie einen Proxy wie stunnel verwenden, um zwischen einem TLS zu übersetzen -verschlüsselte TCP-Verbindung und eine unverschlüsselte. Beispielsweise kann ein Stunnel auf einem Clientcomputer einem regulären (nicht TLS-unterstützenden) E-Mail-Client, der auf den IMAP-Server localhost: 143 verweist, ermöglichen, eine Verbindung zum IMAPS-Server mymailserver: 993 herzustellen Code>; oder stunnel auf einem Servercomputer könnte auf externalip: 443 auf HTTPS-Verbindungen warten und diese an internalserver: 80 weiterleiten, wodurch internalserver (ein HTTP-Server) zugelassen wird ) um eine sichere Kommunikation mit der Welt zu haben, obwohl TLS selbst nicht implementiert wird.

Dies ist wie das Bewegen von Fahrzeugen auf der Straße. So wie die Straße das feste Medium ist und darauf viele Fahrzeugtypen fahren können. Wenn Sie also ein neues Fahrzeug für den Straßenverkehr herstellen, muss das Fahrzeug Reifen haben, die auf dieser Straße fahren können.

Wenn Sie Ethernet als ein Medium betrachten, können verschiedene Netzwerkprotokolle wie IPv4 oder IPv6 übertragen werden. Der Punkt hier ist also, dass das Netzwerkmodell so modular aufgebaut ist, dass Sie Dinge nach Belieben ersetzen können, solange sie bestimmten Schnittstellenspezifikationen entsprechen.

Der modulare Aufbau legt also fest, dass unabhängig von Ihrer internen Arbeitsweise keine Rolle spielt, worauf es ankommt, dass Sie auf bestimmte Weise Eingaben erhalten und eine Ausgabe generieren, die für das nächste Modul verständlich ist.

Nach dem Herstellen einer sicheren Verbindung stellt ein Webbrowser immer noch die gleiche Art von Frage wie

  GET /som/page.html HTTP / 1.1host: www.example.com  

und der Webserver reagieren weiterhin auf die gleiche Weise

  200 OKContent-Type text / html ...  

Der einzige Unterschied besteht darin, dass unter dieser Konversation keine direkte TCP-Verbindung besteht, sondern eine Verschlüsselung. So wie die höheren Schichten "nicht wissen", was TCP normalerweise tut (wie z. B. erneute Übertragung von Paketen, Bestätigung, Fensteranpassung usw.), sind sie sich auch der zugrunde liegenden Verschlüsselung "nicht bewusst".

Genau genommen besteht eine gewisse gegenseitige Abhängigkeit: Die Verschlüsselungsschicht basiert auf der Verwendung eines Zertifikats, das speziell zum FQDN www.example.com gehört und von dem der Server traditionell erst nach Erhalt des Host: Header. Aus diesem Grund können ältere Implementierungen auch mehrere http-vhosts auf einer einzelnen IP-Adresse verarbeiten, jedoch nur einen https-vhost pro IP-Adresse. Dies wurde von SNI behoben.

High-Level-Protokolle sind möglicherweise nicht sicher, wenn sie unverändert mit SSL verwendet werden. Es besteht die Möglichkeit von Seitenkanalangriffen.

Wie andere bereits ausführlich erläutert haben, können Sie mit SSL einen unverschlüsselten Stream in einen verschlüsselten Stream einbinden. Theoretisch sollten keine Informationen über die übertragenen Daten verloren gehen. In der Praxis gibt es ein Datenelement, das immer leckt - die übertragene Datenmenge.

Dies klingt nach einem akzeptablen Leck und ist es in einigen Fällen auch. Es gibt jedoch eine Reihe von Angriffen, wie den CRIME-Angriff und diesen Angriff auf VOIP, die die Tatsache ausnutzen, dass Daten komprimiert werden und die Komprimierungsverhältnisse variieren Abhängig vom Nachrichteninhalt, um Informationen über den Inhalt von Nachrichten zu erhalten.

Andere Seitenkanalangriffe können auch unter Verwendung anderer durchgesickerter Daten möglich sein, z. B. das genaue Timing von Anforderungen und Antworten.

  Http Https + ------------------ + + ------------------ + | 7 http Methoden | | http Methoden | < --- same Keine Änderung erforderlich + ------------------ + + ------------------ + | 6 Daten : ex) "$ 1000" | | Daten: ex) "kf4d3s1" | < --- Daten verschlüsselt + ------------------ + + ------------------ + | 5 Socke: | | Socke: | + ------------------ + + ------------------ + | 4 TCP: | | TCP: | + ------------------ + + ------------------ + | 3 IP: | | IP: | + ------------------ + + ------------------ + | 2 PPP: | | PPP: | + ------------------ + + ------------------ + | 1 RJ45: | | RJ45: | + ------------------ + + ------------------ + 7. Anwendungsschicht -> Http6. Präsentationsschicht -> MIME SSL TLS XDR < ---- Dies ist, was Sie wollen5. Sitzungsschicht -> Sockets4. Transportschicht -> TCP UDP SCTP DCCP3. Netzwerkschicht -> IP IPsec ICMP IGMP OSPF RIP2. Datenverbindungsschicht -> PPP, SBTV, SLIP1. Physische Schicht -> FDDI, B8ZS, V.35, V.24, RJ45.  

Nur die Verhandlungs- / Handshake-Methoden ändern sich für die zusätzliche Verschlüsselung.

HTTPS-Verschlüsselungen eine HTTP-Nachricht (Daten) vor der Übertragung und entschlüsselt sie bei Ankunft

Protokolle höherer Schichten kümmern sich nicht um die Details niedrigerer Schichten . Sie gehen einfach davon aus, dass die unteren Schichten auf irgendeine Weise implementiert wurden, und gehen von dort aus. Wenn wir uns für das TCP / IP-Modell entscheiden, gibt es vier dieser Schichten:

OSI definiert eine physische Schicht, die die Verbindung zweier Computer miteinander übernimmt. TCP / IP nicht, aber es ist nützlich, hier darüber nachzudenken. Twisted-Pair-, Koaxial-, CAT6- und Funkwellen sind einige gängige Methoden zum Verbinden von Maschinen. Sie können jedoch fast alles verwenden, einschließlich Laserstrahlen, Schallwellen und, ja, Brieftauben. P. >

Die Verbindungsschicht, mit der ein Signal über zwei direkt verbundene Maschinen übertragen wird . Die 802.11-Familie (Wi-Fi), die 802.3-Familie (Ethernet) und PPP (Modems) sind heute wahrscheinlich die beliebtesten Protokolle auf der Verbindungsschicht, aber es gibt auch andere.

Die Internetschicht , der ein Signal über zwei Maschinen erhält, die nicht direkt über eine Kette von Maschinen verbunden sind, die sind. Hier lebt IP sowohl in IPv4 als auch in IPv6.

Die Transportschicht, die die Logistik verwaltet, um Signale in einen nutzbaren Datenstrom umzuwandeln . TCP und UDP leben hier ebenso wie einige weniger bekannte Protokolle.

Die Anwendungsschicht, die die von der Transportschicht zusammengestellten Daten interpretiert. Hier hören die meisten Protokolle, die wir häufig über -HTTP, FTP, POP, IMAP usw. hören.

HTTP befindet sich in der Anwendungsschicht . Es wird davon ausgegangen, dass Sie bereits über eine sinnvolle Möglichkeit verfügen, einen Datenstrom zwischen Computern abzurufen, die möglicherweise nicht direkt miteinander verbunden sind. Solange Sie das haben, ist es HTTP egal, woher der Datenstrom kommt. Technisch gesehen müssen Sie im zugrunde liegenden Transport nicht einmal TCP / IP verwenden, obwohl dies in der Praxis fast jeder tut.

Für alltägliche Zwecke befindet sich SSL / TLS in der Transportschicht (die technische Wahrheit ist komplizierter, hat jedoch keine Auswirkungen auf Endbenutzer). Das heißt, Sie geben ihm einen Datenstrom zum Senden und erhalten beim Empfang einen Datenstrom zurück, genau wie TCP / IP. Insbesondere kümmert sich SSL / TLS nicht um den Inhalt seines Datenstroms: Sie können ihn weitergeben, was Sie wollen, und es wird seine Sache tun.

Weil sich keine Schicht darum kümmert, was die andere Wenn Sie dies tun, können Sie sie frei austauschen. HTTP ist glücklich, solange es die gewünschten Streams erhält, und es ist ihm egal, was die zugrunde liegenden Protokolle in der Zwischenzeit mit diesen Streams tun, sodass Sie jedes darunter liegende Transportschichtprotokoll verwenden können. TCP / IP (und SSL / TLS) kümmern sich nicht um den Inhalt der Daten, es sei denn, dies ist erforderlich, um sicherzustellen, dass die resultierenden Daten am anderen Ende genau so aussehen, wie sie vom Benutzer gesendet wurden, sodass Sie jede Anwendung verwenden können -Layer-Protokoll mit ihnen

Ich kenne die OSI-Ebenen

OK, erster Fehler dort - aber wie Sie aus den anderen Antworten gesehen haben, ist dies ein häufiges Missverständnis. TCP / IP ist kein OSI. Es ist älter als OSI, aber einige Jahre. Und es soll nicht einmal dasselbe sein. TCP / IP ist (ein Teil der Schichten) ein Netzwerkprotokoll. OSI ist ein Modell für den Entwurf eines vollständigen Netzwerkprotokolls. Versuchen Sie, TCP / IP in Bezug auf OSI zu erklären, und Sie werden sehr bald nicht mehr weiterkommen, z. HTTP / 2 über TCP / IP? 4 verschiedene Sitzungsebenen, Komprimierung in mindestens 2 separaten Schichten des Stapels.

SSL oder TLS ist eine Methode zum Implementieren einer asymmetrischen Kommunikation über eine beliebige bidirektionale Stream-Schnittstelle. Das heißt, es kann auf TCP / IP, IPX / SPX, Unix-Domain-Sockets, (Vollduplex-) Named Pipes, RS-232 usw. ausgeführt werden. Aber wann haben Sie das letzte Mal ein anderes Datennetz als TCP / IP verwendet?

Luc ist nicht falsch zu sagen, dass SSL / TLS auf UDP ausgeführt werden kann, er erzählt nur nicht die ganze Geschichte - für eine solche Architektur gibt es eine zusätzliche Schicht zwischen den TLS- und UDP-Teilen, die den Stream-Zusammenbau implementiert. Fehlerbehebung und Bandbreitenverwaltung.

In seinem ersten Satz sagt er, dass Protokolle auf höheren Ebenen unverändert bleiben können.

Dies ist falsch, Punkt.

Höhere Ebenen müssen in irgendeiner Weise angeben, dass SSL / TLS verwendet werden sollte; Im Web erfolgt dies mit dem HTTPS: URL-Schema, mit dem Sicherheitsflag für HTTP-Cookies und mit einer HSTS-Richtlinie (HTTP Strict Transport Security).