Hallo allerseits, ich beschäftige mich aktuell mit Verschlüsselungsverfahren (Prüfungsvorbereitung!). Nun habe ich zwar das Prinzip der asymmetrischen Verschlüsselung verstanden, allerdings kann ich die parktische Umsetzung nicht ganz nachvollziehen. Wer übernimmt bei HTTPS und SMTPS die Generierung des Schlüsselpaars und den austausch des Schlüssels? Macht das ein Programm im Hintergrund oder muss ich mich als Benutzer selber darum kümmern? Im Gegensatz dazu habe ich vor Kurzem mit dem SSH-Client Putty auf einen Testserver zugegriffen. Ich musste erst ein Schlüsselpaar generieren und den öffentlichen Schlüssel mit Root-Rechten beim Server hinterlegen. Ich verstehe nicht, warum ich es hier manuell machen musste. Kann mir jemand helfen?
Torben S. schrieb: > Wer übernimmt bei HTTPS und SMTPS die Generierung des Schlüsselpaars und > den austausch des Schlüssels? Die Programme. Torben S. schrieb: > Im Gegensatz dazu habe ich vor Kurzem mit dem SSH-Client Putty auf einen > Testserver zugegriffen. Ich musste erst ein Schlüsselpaar generieren und > den öffentlichen Schlüssel mit Root-Rechten beim Server hinterlegen. Ich > verstehe nicht, warum ich es hier manuell machen musste. Weil es bei SSH auch um Authentifikation geht, nicht (nur) um Transportverschlüsselung.
Jack V. schrieb: > Weil es bei SSH auch um Authentifikation geht, nicht (nur) um > Transportverschlüsselung Wird zwar äußerst selten genutzt ist aber auch mit HTTPS möglich, nennt sich Client-Certificate.
Ich habe es so verstanden, dass HTTPS auch Authentifikation umfasst. Stichwort Server-Zertifikat
HTTPS ist nur HTTP über TLS. Beide Seiten brauchen Zertifikate. Für die Client-Seite kommt das mit dem Browsern mit, um das Serverzertifikat muss sich der Betreiber kümmern. Ein uralter Browser mit abgelaufenen Zertifikat kann keine TLS-Verbindung mehr aufbauen. Beide (beide?) Seiten müssen die Zertifikate mit einem Root-Zertifikat überprüfen.
Torben S. schrieb: > Ich habe es so verstanden, dass HTTPS auch Authentifikation umfasst. > Stichwort Server-Zertifikat Ja, aber das ist ja nur in eine Richtung. D.h. der Server weist seine Identität dem Client nach, aber dann hat der Server immer noch keine Ahnung wer der Client eigentlich ist. Dafür gibt es dann das erwähnte Client Certificate - kann man statt z.B. Username/Passwort benutzen. Stell es Dir vor wie SSH-Zugang mit Zertifikat statt Passwort. Das Problem mit dem nur einseitigem Identitätsnachweis ist übrigens weit verbreitet, z.B. muss zwar Dein Handy der Basisstation seine Identität nachweisen, die Basisstation tut das aber gegenüber dem Handy nicht (AFAIK nichtmal bei 5G). Oder wenn Du die Hotline Deiner Bank anrufst - die wollen dass Du ihnen nachweist wer Du bist, aber ob die Hotline nicht ein Fake ist wird Dir nicht nachgewiesen.
Quatsch. Bei https findet nur eine Server-Authentifikation statt. Was beim Browser mitkommt[1], sind die Root-Zertifikate - die ersetzen das manuelle Übertragen des Public-Keys bei ssh[2]. Eine Authentifikation des Clients gegenüber dem Server findet nicht statt. Ob der Client bei abgelaufenen oder ungültigen Zertifikaten (egal ob Server oder Root) die Verbindung abbricht, entscheidet er selbst - gezwungen ist er nicht. Die Verschlüsselung selbst geschieht mit einem Session-Key, der bei jedem Verbindungsaufbau neu generiert wird. [1] Kann auch vom System kommen. [2] Zeigt auch gleich das Problem bei https: ein Dritter entscheidet, welchen Servern du trauen sollst.
Man kann auch bei HTTPS mit Client-Zertifikaten arbeiten, d.h. der Server lässt dann nur entsprechende Clients rein. Es ist nur unüblich.
Ich schrieb: > Quatsch. [...] Das bezog sich auf den Artikel von muellernick, nicht auf den vom Alten Sack. prx: > Man kann auch bei HTTPS mit Client-Zertifikaten arbeiten, Missverständis. Mir ging es um die Behauptung, dass der Browser ein Client-Zertifikat mitliefert/eingebaut hätte. Noch ist es nicht so weit ;-) Dass es Client-Zertifikate gibt, wollte ich nicht bestreiten (ist mir aber allerdings nie untergekommen - gibt's da in den modernen Browsern überhaupt noch ne GUI für?).
Angehängte Dateien:
-
cert.png
66 KB
Firefox Zertifikatverwaltung, siehe Bildschirmfoto. Offensichtlich lassen die sich auch importieren. Und jedenfalls ist es so, dass bei einer TLS-Verbindung (das ist HTTPS, SSH, VPN, ...) beide Seiten Zertifikate erfordern können. Und genau darum ging es in der Frage des TO.
> Firefox Zertifikatverwaltung, siehe Bildschirmfoto. Das sind die Root-Zertifikate - damit werden die Server-Zertifikate überprüft und die haben nichts mit Client-Zertifikaten zu tun (die könnten unter einem der anderen Reitern stecken und werden bei dir wohl leer sein). > Und jedenfalls ist es so, dass bei einer TLS-Verbindung (das ist > HTTPS, SSH, VPN, ...) beide Seiten Zertifikate erfordern können. HTTPS kann, ja, tut es in der Praxis aber nur einseitig. Und z.B. SSH benutzt gar keine Zertifikate - die Authentisierung geschieht manuell. > Und genau darum ging es in der Frage des TO. Ihm ging es darum, wie HTTPS die Keys generiert und übermittelt. Dafür sollte er z.B. mal nach "Diffie-Hellman Key Exchange" suchen. Der ganze Zertifikatskram ist da draufgesetzt und hat erstmal nichts mit der Verschlüsselung zu tun.
Entschuldigt, der Grund, warum man sich bei SSH das Schlüsselpaar selber erstellen muss und bei HTTPS, FTPS und SMTPS nicht, will nicht in meinen Kopf rein. Jack V. schrieb: > Weil es bei SSH auch um Authentifikation geht, nicht (nur) um > Transportverschlüsselung. Kann ich leider nicht nachvollziehen. Bei HTTPS geht es auch um Authentifizierung und trotzdem muss ich das Schlüsselpaar nicht selbst generieren. (Das soll kein Angriff sein, das liegt an an meiner eingeschränkten Sichtweise) Alter Sack schrieb: > D.h. der Server weist seine Identität dem Client nach, aber dann hat der > Server immer noch keine Ahnung wer der Client eigentlich ist. Dafür gibt > es dann das erwähnte Client Certificate - kann man statt z.B. > Username/Passwort benutzen. Stell es Dir vor wie SSH-Zugang mit > Zertifikat statt Passwort. Client Zertifikat heißt dann übersetzt, der Server benötigt meinen öffentlichen Schlüssel, damit er meine Nachrichten entschlüsseln kann. Die schlüssel werden, wie Jack schreibt, von Programmen generiert. Ich kann den Zusammenhang zu der Frage, warum man die Schlüssel nicht manuell wie bei SSH generieren muss nicht erkennen. (Ich danke dir trotzdem für deine Antwort). Was ich aber den Antworten entnehmen kann ist, dass eine Authentifikation des Clients gegenüber dem Server nicht die Regel ist? Dafür braucht man ein extra Client Zertifikat?
Torben S. schrieb: > Was ich aber den Antworten entnehmen kann ist, dass eine > Authentifikation des Clients gegenüber dem Server nicht die Regel ist? > Dafür braucht man ein extra Client Zertifikat? Ja, ja. Schau dir TLS an, denn um mit einem HTTPS-Server zu kommunizieren, macht der Client zuerst einen socket auf, dann läuft das TLS handshake und sobald das etabliert ist, sendet man einfach unverschlüsselte Daten an den socket. TLS hat sich aber bildlich hinter dem Socket reingehängt und verschlüsselt die Kommunikation bevor sie den Rechner verlässt. HTTP ist einfach nur ein Übertragungsprotokoll zwischen Server und Client (Browser). Das S im HTTPS sagt nur aus, dass es übereinen secure socket läuft. das HTTP-Protokoll bleibt davon völlig unberührt.
Torben S. schrieb: > Entschuldigt, der Grund, warum man sich bei SSH das Schlüsselpaar selber > erstellen muss und bei HTTPS, FTPS und SMTPS nicht, will nicht in > meinen Kopf rein. "USING OPENSSH CERTIFICATE AUTHENTICATION https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication Es ist kein Zufall, dass Zertifikatsgenerierung ziemlich häufig mit openssh durchgeführt wird. CA-Generierung und Signierung inklusive.
:
Bearbeitet durch User
Torben S. schrieb: > Alter Sack schrieb: >> D.h. der Server weist seine Identität dem Client nach, aber dann hat der >> Server immer noch keine Ahnung wer der Client eigentlich ist. Dafür gibt >> es dann das erwähnte Client Certificate - kann man statt z.B. >> Username/Passwort benutzen. Stell es Dir vor wie SSH-Zugang mit >> Zertifikat statt Passwort. > > Client Zertifikat heißt dann übersetzt, der Server benötigt meinen > öffentlichen Schlüssel, damit er meine Nachrichten entschlüsseln kann. Genau. Und diesen Schlüssel musst Du selbst erzeugen, sowohl bei SSH als auch, wenn es halt verwendet wird, bei Webserver mit TLS. Weil der private Schlüssel dazu ist halt das - privat, nur Dir bekannt. > Die schlüssel werden, wie Jack schreibt, von Programmen generiert. Ich > kann den Zusammenhang zu der Frage, warum man die Schlüssel nicht > manuell wie bei SSH generieren muss nicht erkennen. (Ich danke dir > trotzdem für deine Antwort). Du unterliegst da einem Irrtum - natürlich muss der Schluessel für den TLS-, SSH-, SFTP-Server auch von jemandem generiert und hinterlegt werden, vom Admin dieses Servers (manchmal machen das auch Skripte automatisch für den Admin). Mindestens bei bei denen für öffentliche Webserver mit TLS ist das sogar ein ziemlich involvierter Prozess und kostet oft auch Geld. Kannst Du nachlesen, Stichwort zum Beispiel CA - Certicate Authority, oder z.B. bei www.digicert.com so einen Dienstleister ansehen. > Was ich aber den Antworten entnehmen kann ist, dass eine > Authentifikation des Clients gegenüber dem Server nicht die Regel ist? > Dafür braucht man ein extra Client Zertifikat? Ja. Wobei es oft ja auch nicht gebraucht wird, ein öffentlicher Webserver wie z.B. die Google-Suchmaschine oder sagen wir heise.de hat ja keinen Bedarf den Benutzer zu kennen.
Vorgabe: 1 SSH/Webserver, N SSH/Web-Clients. Ein Webserver authentifiziert sich gegenüber dem Browser. Weshalb man für den Webserver ein Zertifikat benötigt. Der Browser hingegen authentifiziert sich normalerweise nicht gegenüber dem Server. Die Authentifizierung ist also einseitig. Aufwand 1: 1 Key/Zertifikat für den Server. Ein SSH-Client authentifiziert sich gegenüber dem SSH-Server. Weshalb man für jeden Client einen eigenen Key benötigt. Aber da ist es - anders als beim Webserver - eine zweiseitige Sache. Der Server will wissen, dass der Client echt ist, und der Client will wissen, dass er mit dem richtigen Server kommuniziert, nicht mit einem Schlapphut dazwischen. Aufwand N+1: 1 Key für den Server, je einen für N Clients. Also: Aufwand(Webserver)=1, Aufwand(SSH)=N+1. Hat man eine kleine Umgebung, kann man bei SSH den Schlüsselkram überall rumkopieren. Ist sie grösser, arbeitet man auch bei SSH mit CAs, so wie bei Webservern auch.
:
Bearbeitet durch User
> Entschuldigt, der Grund, warum man sich bei SSH das Schlüsselpaar selber > erstellen muss und bei HTTPS, FTPS und SMTPS nicht, will nicht in > meinen Kopf rein. Das Schlüsselpaar, dass du bei SSH erstellst, dient nicht der Verschlüsselung der Verbindung sondern der Authentisierung des Clients. Wenn es der SSH-Server erlaubt, kannst du auch eine Passwort-Authentisierung durchführen, dann brauchst du kein Schlüsselpaar. Bei HTTPS authentisiert sich der Client üblicherweise nicht. Wenn das benötigt wird, findet das auf einem höheren Layer statt, z.B. mittels HTTP-digest (inzw kaum noch in Benutzung) oder anwendungsspezifisches Einloggen.
Torben S. schrieb: > Wer übernimmt bei HTTPS und SMTPS die Generierung des Schlüsselpaars und > den austausch des Schlüssels? Macht das ein Programm im Hintergrund oder > muss ich mich als Benutzer selber darum kümmern? Der Schlüsselaustausch ist Teil des Handshakes, darum must du dich im Bezug auf die Verschlüsselung nicht selbst kümmern. Interessanter ist die Authentifizierung. Bei TLS arbeitest du in der Regel mit einer einseitigen Authentifizierung. D.h. der Server authentifiziert sich bei dir und das passiert im Browser durch die vorinstallierten Zertifikate der CAs. Im Gegensatz zu SSH gibt es bei TLS Zertifikatsketten. D.h. ein Zertifikate ist nicht nur dann gültig wenn du vorher exakt dieses Zertifikat ausgetauscht hast, sondern es kann (genau genommen muss es) auch durch ein anderes Zertifikat welches vorher ausgetauscht wurde bestätigt werden.
foobar schrieb: > Quatsch. Bei https findet nur eine Server-Authentifikation statt. Was > beim Browser mitkommt[1], sind die Root-Zertifikate - die ersetzen das > manuelle Übertragen des Public-Keys bei ssh[2]. Eine Authentifikation > des Clients gegenüber dem Server findet nicht statt. Ob der Client bei > abgelaufenen oder ungültigen Zertifikaten (egal ob Server oder Root) die > Verbindung abbricht, entscheidet er selbst - gezwungen ist er nicht. > > Die Verschlüsselung selbst geschieht mit einem Session-Key, der bei > jedem Verbindungsaufbau neu generiert wird. > > > [1] Kann auch vom System kommen. > [2] Zeigt auch gleich das Problem bei https: ein Dritter entscheidet, > welchen Servern du trauen sollst. Dem ist eigentlich nichts hinzuzufügen. So sehe ich das auch.
Torben S. schrieb: > Entschuldigt, der Grund, warum man sich bei SSH das Schlüsselpaar selber > erstellen muss und bei HTTPS, FTPS und SMTPS nicht, will nicht in > meinen Kopf rein. Also gut, dann erkläre ich es nochmal. Bei SSH hast du zwei Einheiten, die miteinander kommunizieren. Der Server und der Client. Will der Client nun wissen, ob der Server wirklich ist, der er vorgibt zu sein, muss er den Fingerprint des Servers beim ersten Login, mit dem Fingerprint des Servers, den er sich über einen dritten Weg besorgt, vergleichen. Der dritte Weg ist bspw. dass der Nutzer sich lokal beim Server einloggt, den Fingerprint am Bildschirm ausgibt und auf Papier aufschreibt. Dann hat er ihn. Jetzt geht er nach Hause und macht seinen SSH Verbindungsaufbau. Der Server zeigt seinen Fingerprint an und jetzt wird der mit dem auf dem Papier verglichen. Stimmt das überein, dann ist es der echte Server mit dem man kommunzieren wollte. Ist der Fingerprint falsch, hat man wohl nen Man in the Middle, der nur vorgibt der Server zu sein, aber nicht ist. Bei HTTPS ist das etwas anders. Da hat man Verständlichkeit vereinfacht dargestellt 3 Einheiten. Den Client, den Server und die Certificate Authority (kurz CA). Der Server hat ein Zertifikat, dass er sich von der CA zertifieren lassen hat, damit weist er sich aus. Der Client hat die Public Keys der CA, die werden immer mit installiert und mit dem Browser downgeladen. Guck dazu mal in deinen /usr/share/ca-certificates/mozilla/ Ordner. Bei Updates werden ab und zu auch mal diese CA Dateien erneuert oder aktualisiert. Mit diesen Public Keys der CA kann nun der Client das Zertifikat des Servers überprüfen. Das ist vereinfacht gesagt vergleichbar mit OpenPGP wo du mit deinem privaten Key eine Datei unterschreibst und eine Signaturdatei *.sig mitlieferst. Der Empfänger kann dann mit deinem Public Key diese Signatur auf Echtheit überprüfen. Die obige Darstellung mit dem Serverzertifikat und dem CA habe ich stark vereinfacht. In der Realität kommen noch Zwischenzertifikate dazu, die Zwischenzertifikate werden von den Pivate Keys der CAs signiert und können dann mit dem Public Key des CA, die dein Browsers mitführt überprüft werden. Die Serverzertifiakte werden in der Realität aber nicht von der CAs signiert, sondern von den Private Keys der Zwischenzertifkate und damit dein Browser das Serverzertifikate überprüfen kann, überprüft er das Zwischenzertifikat mit dem Public Key der mitgeschleppten CAs. Vertraut er dem CA, dann ist das Zwischenzertifikat echt und somit auch dessen Public Key. Und dieser Public Key, sendet, wenn ich mich nicht irre, der Server selber aus, zusätzlich zu seinem eigenen Zertifikat. > Jack V. schrieb: >> Weil es bei SSH auch um Authentifikation geht, nicht (nur) um >> Transportverschlüsselung. > > Kann ich leider nicht nachvollziehen. Bei HTTPS geht es auch um > Authentifizierung und trotzdem muss ich das Schlüsselpaar nicht selbst > generieren. (Das soll kein Angriff sein, das liegt an an meiner > eingeschränkten Sichtweise) Das Schlüsselpaar bestehend aus Public Key und Private Key für das Zertifikat der CA wird von der CA generiert. Das SChlüsselpaar bestehend aus PubK und PrivK für das Zwischenzertifkat wird vom Zwischenzertifikatbetreiber generiert, aber von der CA signiert. Das Schlüsselpaar bestehend aus PubK und PrivK für das Zertifikat vom Server, wird vom Serverbetreiber generiert, aber vom privaten Key des Zwischenzertifikatbetreibers signiert. Am besten ist es, wenn du dir mal anschaust wie du dir deine eigene CA erstellst und wie du bspw. deine Fritzbox und deinen Drucker und dein NAS mit einem Zertifikat ausstattest, dass du mit deiner CA signierst. So lernst du das am besten. Lies dir dazu mal am besten folgenden Artikel durch und folge den Anweisungen: https://wiki.ubuntuusers.de/CA/#Eigene-CA-betreiben > Alter Sack schrieb: >> D.h. der Server weist seine Identität dem Client nach, aber dann hat der >> Server immer noch keine Ahnung wer der Client eigentlich ist. Dafür gibt >> es dann das erwähnte Client Certificate - kann man statt z.B. >> Username/Passwort benutzen. Stell es Dir vor wie SSH-Zugang mit >> Zertifikat statt Passwort. > > Client Zertifikat heißt dann übersetzt, der Server benötigt meinen > öffentlichen Schlüssel, damit er meine Nachrichten entschlüsseln kann. > Die schlüssel werden, wie Jack schreibt, von Programmen generiert. Ich > kann den Zusammenhang zu der Frage, warum man die Schlüssel nicht > manuell wie bei SSH generieren muss nicht erkennen. (Ich danke dir > trotzdem für deine Antwort). Der Browser macht das automatisch für dich. Bei ssh ist es auch nur ein starten des ssh-keygen Programms + entsprechende Parameter. Beachte aber, dass die Public und Privat Key, also asymmetrischer Schlüssel Geschichte NUR zum authentifizieren und zum Schlüsselaustausch eines symmetrischen Sitzungsschlüssels stattfindet. Die eigentliche Datenkommunikation findet dann danach verschlüsselt mit dem Sitzungsschlüssel statt. Der Server selbst braucht kein authentifiziertes Client Certifikate, da dieses ja nur zum Aushandeln des Symmetrischen Sitzungsschlüssels verwendet wird. Authentifizierten tust du dich gegenüber dem Server dann nachträglich über die dann bestehende verschlüsselte Verbindung mit deinem Nutzeraccount und Passwort. Für den Account musst du dich vorher natürlich registriert haben. > Was ich aber den Antworten entnehmen kann ist, dass eine > Authentifikation des Clients gegenüber dem Server nicht die Regel ist? Richtig, im Prinzip ist die Authentifzierung des Clients gegenüber dem Server in dieser Phase noch nicht nötig. Es geht nur um den Austausch eines symmetrischen Sitzungsschlüssel auf den sich beide Parteien einigen. Und authentifizieren tust du dich dann nachher über die verschlüsselte HTTSP Verbindung mit deinen Accountdaten. > Dafür braucht man ein extra Client Zertifikat? Das Client Zertifikat braucht man immer, aber es kann beliebig generiert sein, da es nur zum Austausch des symmetrischen Sitzungsschlüssels dient. Und solange die Verbindung besteht, weiß ja der Server, wer der Client ist und unter welcher IP er ihn erreicht.
@Nano Daumen hoch für die super Erklärung und auch den anderen herzlichen dank für eure kompetente Hilfe. Ich habe es jetzt kapiert!
Ich hätte nochmal 'ne Rückfrage. Wenn es um Beispiele der asymmetrischen Verschlüsselung geht, lese ich oft HTTPS. Wenn ich mir das Verfahren dann aber bei Wikipedia durchlese, verstehe ich es sinngemäß so, dass ein Session-Key ausgehandelt und zur Verschlüsselung der Nachricht verwendet wird und dass nur dieser Sessions-Key asymmetrisch verschlüsselt wird. Meine Frage: Wäre das dann nicht eine hybride Verschlüsselung und gibt es auch Beispiele für reine asymmetrische Verschlüsselungen bzw. PKIs?
foobar schrieb: > HTTPS kann, ja, tut es in der Praxis aber nur einseitig. Da muss ich mal reingrätschen. Das stimmt einfach nicht. Es ist in der Praxis weit verbreitet, nur sieht du es nicht. HTTPS, also HTTP über TLS wird nicht nur zwischen Webbrowsern und Webservern verwendet. HTTPS wird auch massenweise zwischen Diensten verwendet. Willkommen in der Welt der Cloud mit Webservices und Microservices. Da ist man ganz scharf auf REST-APIs, SOAP über HTML und ähnlichen Blödsinn. Wenn nötig sichert man das dann mit mTLS ab, was für mutual-TLS steht und nichts anderes meint, als dass man auf dem TLS-Layer unter HTTP auch das TLS-Feature für Client-Authentifizierung nutzt. Also gegenseitige Authentifizierung. Wenn man ganz schräg drauf ist, dann nimmt man noch ein automatisches Zertifikat-Verteilungssystem dazu. Ziemlich dubios, aber da stehen die Cloud-Leute drauf. Das in ein Service-Mesh gepackt oder als integraler Teil eines solchen (alter Fehlschluss der Informatiker: Jedes Problem lässt sich mit einer weiteren Abstraktionsebene lösen), und du hast so in etwa das was in Google, Amazon, Alibaba, Tencent und anderen Cloud-Diensten abläuft. Wer mal sehen will wie mTLS mit Zertifikatverteilung in ein Service-Mesh eingebunden ist: https://istio.io/latest/docs/concepts/security/ Neben der Verbreitung bei Dienste-zu-Dienste Kommunikation findest du mTLS auch unter der Haube bei Dienste-zu-Anwender Kommunikation unter der Haube. Zum Beispiel unterstützt Skype-for-Business das.
Torben S. schrieb: > gibt > es auch Beispiele für reine asymmetrische Verschlüsselungen bzw. PKIs? Meiner Erinnerung nach, das ist nicht mein Spezialgebiet, war das beim ursprünglichen PGP so: ich habe Mails manuell mit dem öffentlichen Key des Empfängers verschlüsselt und versendet, der Empfänger konnte sie mit seinem Privatkey dekodieren. Ein ungelöstes Problem dabei ist dabei die Frage, wie komme ich gesichert zum öffentlichen Key meines Geschäftspartners - der kann ihn auf seiner Website veröffentlichen, aber das könnte manipulierbar sein. Post ist eine Möglichkeit. Ich habe aber PGP seit vielen Jahren nicht mehr benutzt. Georg
Auch PGP/GPG verwendet im Kern symmetrische Verschlüsselung. Nur der zufällig erzeugte Schlüssel dafür wird asymmetrisch verschlüsselt, und in dieser Form mit dem Paket übertragen. Symmetrische Verschlüsselung ist um viele Grössenordnungen schneller.
:
Bearbeitet durch User
@A.K. habe ich das richtig verstanden? Dort wo man einen symmetrischen Schlüssel über asymmetrische Verschlüsselung austauscht, spricht man von hybrider Verschlüsselung. Das träfe dann aber auf die meisten Protokolle zu. Rein asymmetrische Verschlüsselung hätte man demnach ja nur bei SSH.
Torben S. schrieb: > @A.K. habe ich das richtig verstanden? Dort wo man einen symmetrischen > Schlüssel über asymmetrische Verschlüsselung austauscht, spricht man von > hybrider Verschlüsselung. Das träfe dann aber auf die meisten Protokolle > zu. Ja. > Rein asymmetrische Verschlüsselung hätte man demnach ja nur bei SSH. Auch SSH verwendet beim eigentlichen Transport symmetrische Verschlüsselung.
:
Bearbeitet durch User
Georg schrieb: > Ein ungelöstes Problem dabei ist dabei die > Frage, wie komme ich gesichert zum öffentlichen Key meines > Geschäftspartners So ein Problem löst man (teilweise) mit Zertifikaten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.