Frage:
Was ist der Unterschied zwischen SSL und SSH? Welches ist sicherer?
Am1rr3zA
2011-01-13 15:40:18 UTC
view on stackexchange narkive permalink

Was ist der Unterschied zwischen SSH und SSL? Welches ist sicherer, wenn Sie sie miteinander vergleichen können?
Welches hat mehr potenzielle Schwachstellen?

Dies ist keine echte Frage. Sie vergleichen Äpfel und Orangen. Was helfen könnte, wäre, wenn Sie erklären könnten, warum Sie es wissen wollen - da dies als Leitfaden für Antworten dienen könnte. ZB möchten Sie eine sichere Zugriffslösung implementieren und suchen die am einfachsten zu sichernde?
@Rory Ich glaube nicht, da ich weiß, dass beide einen ähnlichen Job machen (ich vergleiche keine Äpfel und Orangen), aber vielleicht irre ich mich, also werde ich dankbar, wenn die Community mir meinen Fehler zeigt.
@Am1rr3zA, ist es nicht genau richtig, dass sie einen ähnlichen Job machen. In der Praxis werden SSL und SSH normalerweise für unterschiedliche Zwecke verwendet: SSH wird am häufigsten für die Remote-Anmeldung verwendet, SSL für den verschlüsselten Webzugriff.
@D.W. Es sieht so aus, als würden sie manchmal für dasselbe verwendet, z. ** SFTP ** scheint auf * SSH * zu basieren, während ** FTPS ** auf * SSL * basiert.
Wenn wir uns von der sinnvollen Verwendung dieser beiden Protokolle scheiden lassen, ist die Frage für ihre Absicht von Bedeutung. Eine Analogie. Was ist sicherer? 1.) Ein Deibold-Bank-Safe mit magnetischen Failafes? 2.) Ein 26-stelliges Passwort, das sich täglich ändert und 1024-Bit-verschlüsselt ist? Die meisten Leute würden das Apfel-Orangen-Debakel erleben. Ignorieren Sie, dass einer den Zugang zu einem elektronischen Gerät schützen soll und der andere physisch ist und Bargeld schützen soll. WAS DIE GRÖSSERE LEISTUNG UND ZEIT ERFORDERT, UM KOMPROMISS ZU ERREICHEN. Das ist wirklich was er fragt. Wenn wir mit dieser Einstellung antworten, kann dies beantwortet werden.
In ihrem eigenen Element hat jeder eine Stärke. Betrachten Sie es also einfach aus einer Hack-Perspektive. Was würdest du lieber hacken? Außerdem sollte die Frage gestellt werden "Was ist sicherer für den Zweck von ... XYZ", da er die Frage gestellt hat, ohne den Zweck anzugeben, an dem alle aufgehängt wurden. Mein Beispiel mit dem Safe vs. Die Anmeldung zeigt zwei verschiedene Zwecke (bei denen die Leute sagten "Hey, diese beiden Protokolle und ihre Sicherheit erfüllen normalerweise nicht die gleiche Funktion" und das ist absolut richtig. Einer ist möglicherweise immer noch "sicherer" als der andere.
Acht antworten:
#1
+206
Thomas Pornin
2011-01-13 20:55:15 UTC
view on stackexchange narkive permalink

SSL und SSH stellen beide die kryptografischen Elemente bereit, um einen Tunnel für den vertraulichen Datentransport mit überprüfter Integrität zu erstellen. Für diesen Teil verwenden sie ähnliche Techniken und können unter der gleichen Art von Angriffen leiden. Daher sollten sie eine ähnliche Sicherheit (d. H. Gute Sicherheit) bieten, vorausgesetzt, sie sind beide ordnungsgemäß implementiert. Dass beide existieren, ist eine Art NIH -Syndrom: Die SSH-Entwickler sollten SSL für den Tunnelteil wiederverwendet haben (das SSL-Protokoll ist flexibel genug, um viele Variationen zu berücksichtigen, einschließlich der Nichtverwendung von Zertifikaten).

Sie unterscheiden sich in den Dingen, die sich um den Tunnel herum befinden. SSL verwendet traditionell X.509-Zertifikate zum Ansagen öffentlicher Server- und Clientschlüssel. SSH hat ein eigenes Format. Außerdem enthält SSH eine Reihe von Protokollen für innerhalb des Tunnels (Multiplexen mehrerer Übertragungen, Durchführen einer kennwortbasierten Authentifizierung innerhalb des Tunnels, Terminalverwaltung ...), während es in SSL keine solche Funktion gibt oder genauer gesagt, wenn solche Dinge in SSL verwendet werden, werden sie nicht als Teil von SSL betrachtet (wenn wir beispielsweise eine kennwortbasierte HTTP-Authentifizierung in einem SSL-Tunnel durchführen, sagen wir, dass dies Teil von "HTTPS" ist, aber Es funktioniert wirklich ähnlich wie bei SSH.

Konzeptionell könnten Sie SSH nehmen und den Tunnelteil durch den von SSL ersetzen. Sie können auch HTTPS verwenden und das SSL-Element durch SSH-mit-Datentransport und einen Hook ersetzen, um den öffentlichen Serverschlüssel aus seinem Zertifikat zu extrahieren. Es gibt keine wissenschaftliche Unmöglichkeit und bei richtiger Vorgehensweise würde die Sicherheit gleich bleiben. Es gibt jedoch keine weit verbreiteten Konventionen oder vorhandenen Tools dafür.

Wir verwenden also nicht SSL und SSH für die gleichen Dinge, aber das liegt daran, welche Tools in der Vergangenheit mit den Implementierungen dieser Protokolle geliefert wurden. nicht aufgrund eines sicherheitsrelevanten Unterschieds. Und wer auch immer SSL oder SSH implementiert, sollte sich ansehen, welche Art von Angriffen auf beide Protokolle versucht wurden.

Gut gemacht. Da SSH einfacher einzurichten ist als SSL, tunneln viele Leute http (nicht https) in SSH, z. Remote-Systemadministration mit einem Web-GUI-Tool wie ebox oder webmin.
Nur um darauf hinzuweisen, es ist nicht ganz richtig, dass die SSH-Leute "* sollten *" SSL verwendet haben: SSH wurde sehr speziell entwickelt, um eine kleine Angriffsfläche zu haben und sehr sicher zu sein. SSHv2 hat keine der Probleme und Fallstricke in SSL / TLS. Mit einer kleineren Sache, die sie gut verstanden haben, mit weniger Komplexität, haben sie etwas herausgebracht, das viel besser zu ihrer Situation passt. Es hängt davon ab, wie paranoid Sie sind: SSL ist je nach Anwendung nicht unbrauchbar, aber das Design von SSH macht es in Situationen / Sicherheitsgemeinschaften akzeptabel, in denen SSL einfach nicht vertrauenswürdig ist.
@NicholasWilson "_SSHs Design macht es in Situationen / Sicherheitsgemeinschaften akzeptabel, in denen SSL einfach nicht vertrauenswürdig ist_" wie ...
SSL und SSH wurden parallel entwickelt (beide wurden 1995 veröffentlicht), daher ist nicht klar, ob SSH überhaupt SSL hätte verwenden können. Ob es das zeitgenössische SSL 2.0 hätte verwenden sollen, ist auch sehr zweifelhaft :-)
Nun, SSH 2.0 war eine vollständige Überarbeitung des Protokolls und erschien einige Zeit um 1999, so dass man SSL 3.0 oder sogar TLS 1.0 wiederverwenden konnte. Aber natürlich scheint TLS mit X.509 verbunden zu sein, was Entwickler abschreckt.
@ThomasPornin, SSL kam vor SSH?
@NicholasWilson, Wow, Sie sagen also, dass ** SSHs Sicherheit SSL schlägt **?Was ist mit der Antwort von user185, in der das vollständige Gegenteil angegeben ist?
Ja, ich denke, dass die Transport- / Verschlüsselungsschicht von SSH SSL vorzuziehen ist - aus den Gründen, die verschiedene Personen oben angegeben haben (# 1 übermäßige Komplexität von SSL aufgrund einer großen Anzahl von Patches im Protokoll, um Designfehler zu mindern. Sogar bis zu TLS1.1 Es gibt Unmengen von Dingen, die einfach keine Best Practices sind, und SSH 2.0 hat seine Probleme im Laufe der Jahre behoben, während ein klares Design beibehalten wurde. # 2 X.509 bietet eine riesige Befestigungsfläche für TLS.
user185 sendet, um SSL mit dem SSH-Anwendungsprotokoll zu vergleichen, was nicht wirklich fair ist.SSH verfügt über ein mehrschichtiges Protokollmodell, von dem nur die unterste Schicht mit SSL vergleichbar ist, und würde es jeden Tag in Bezug auf Größe und Einfachheit der Implementierung übertreffen.
@NicholasWilson: Vielen Dank für diesen Einblick.Ich bin derzeit auf der Suche nach Best Practices für die Erstellung einiger immergrüner kryptografisch sicherer Kapselungssysteme in einigen Langzeitprojekten - eines ist ein signiertes (Klartext-) Archivformat, das andere ist die Verschlüsselungsschicht eines Drahtprotokolls für ein MessagingSystem.Ich habe mich auch lange gefragt, ob ich als gigantisches Experiment einen blitzschnellen Ersatz für SSH konstruieren soll.Ich wollte diese Zusammenhänge erwähnen, falls Sie zufällig einige gute Ausgangspunkte kennen.
TLS scheint ein extrem schweres System mit einer langen Geschichte und vielen Komplexitätsebenen zu sein, um Abwärtskompatibilität und Interoperabilität zu gewährleisten.Ich gehe davon aus, dass ich nicht alles benötige, um eine gute Sicherheit zu schaffen, aber meine Schwierigkeit besteht darin, die Kreuzkompatibilität und die "bürokratischen" Aspekte zu identifizieren und gleichzeitig die wichtigen Teile der Maschinen beizubehalten, die zur Sicherheit des Systems beitragen.Ich denke, was ich sage ist, dass TLS als "Verwenden Sie einfach TLS und Sie werden in Ordnung sein" erkannt wird, aber es gibt keine kollektiven Vorstellungen darüber, welche Low-Level-Komponenten auch ähnlich gut / sicher / effektiv / etc. Sind.
Ich denke, meine letzte Frage wäre, in Anbetracht des Detaillierungsgrades, den ich erreichen möchte (und keine Angst davor habe), welche Bestandteile von SSH grundsätzlich besser sind als TLS?Okay, also hat SSH kein X.509.Welche anderen Unterschiede / pros / cons gibt es?- Vielen Dank für Ihre Zeit.
Warum nicht die RFCs lesen - und der OpenSSH-Quellcode ist auch gut lesbar.Einige Dinge, auf die Sie achten sollten: PRF-Definition, Host-Authentifizierung, MAC-Konstruktion.Verwenden Sie einfach SSH, anstatt ein eigenes Protokoll zu erstellen.Sie können einfach die OpenSSH-Transportschicht abrufen und am Ende Code aufrufen, der ungefähr so komplex ist wie die Verwendung von TLS aus OpenSSL (jedoch ein einfacheres Kabelprotokoll).
Faszinierende Antwort von @ThomasPornin, wie gewohnt.Es wäre interessant, die von SSL bzw. SSH verwendeten schlüsselbasierten Clientauthentifizierungsmethoden zu vergleichen / gegenüberzustellen - d. H. Von SSL verwendete Clientzertifikate und von SSH verwendete Authentifizierung mit öffentlichem Schlüssel.
#2
+87
user185
2011-01-13 15:58:16 UTC
view on stackexchange narkive permalink

Dies ist kein vernünftiger Vergleich. SSL ist eine allgemeine Methode zum Schutz von Daten, die über ein Netzwerk transportiert werden, während SSH eine Netzwerkanwendung zum Anmelden und Freigeben von Daten mit einem Remotecomputer ist.

Der Schutz der Transportschicht in SSH ähnelt in seiner Fähigkeit SSL. Was also "sicherer" ist, hängt davon ab, was Ihr spezifisches Bedrohungsmodell erfordert und ob die Implementierungen der einzelnen Probleme die Probleme beheben, mit denen Sie sich befassen möchten.

SSH verfügt dann über eine Benutzerauthentifizierungsschicht, der SSL fehlt (weil es nicht benötigt wird - SSL muss nur die beiden Verbindungsschnittstellen authentifizieren, die SSH auch kann). In UTF-8-Grafik:

  SSL SSH + ------------- + + ----------------- + | Nichts | | RFC4254 | Verbindungsmultiplex + ------------- + + ----------------- + | Nichts | | RFC4252 | Benutzerauthentifizierung + ------------- + + ----------------- + | RFC5246 | | RFC4253 | Verschlüsselter Datentransport + ------------- + + ----------------- +  

Bezüglich des Problems Von denen es mehr potenzielle Angriffe gibt, scheint es klar zu sein, dass SSH eine größere Angriffsfläche hat. Aber das liegt nur daran, dass in SSH eine ganze Anwendung integriert ist: Die Angriffsfläche von SSL +, welche Anwendung Sie auch immer bereitstellen müssen , kann nicht verglichen werden, da wir nicht über genügend Informationen verfügen.

-1 Es ist ein vernünftiger Vergleich. Sie gehen fälschlicherweise davon aus, dass OP SSL mit dem Unix-Programm [ssh (1)] vergleicht (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1). SSH ist eigentlich ein weiteres Protokoll, das Sicherheit auf Transportschicht bietet und besondere Bestimmungen für Remote-Shells und Remote-Ausführung enthält.
+1 @jpillora Obwohl ich damit einverstanden bin, dass es sinnvoll ist, die beiden zu vergleichen, wird der Begriff SSH normalerweise nicht verwendet, um sich auf die Teilmenge des SSH-Protokolls zu beziehen, die die Sicherheit der Transportschicht behandelt, die direkt mit SSL / TLS vergleichbar wäre. Es wird fast ausschließlich in Bezug auf das Anwendungsschichtprotokoll verwendet, das sich in der in dieser Antwort beschriebenen Weise von SSL / TLS unterscheidet.
@freb die Art und Weise, wie sie allgemein bezeichnet werden, ändert nichts an der Wahrheit der Sache. SSH ist ein Protokoll, das als Transportschicht für das Dienstprogramm ssh verwendet wird. Die akzeptierte und am meisten gewählte Antwort spiegelt diese Tatsache wider.
@jpillora Ich meinte lediglich, dass ich nicht denke, dass das SSH-Transportschichtprotokoll das ist, was die meisten Leute angesichts der Formulierung der Frage meinen würden. Angesichts der Antwort, die als richtig akzeptiert wurde, muss es jedoch das gewesen sein, was OP gefragt hat.
@freb Richtig, die meisten Leute denken, dass angesichts der Formulierung, was es noch wichtiger macht, dieses häufige Missverständnis zu korrigieren.
[SSL / TLS] (http://security.stackexchange.com/a/40038/29832) enthält Bestimmungen, mit denen [der Client authentifiziert werden kann] (https://en.wikipedia.org/wiki/Transport_Layer_Security#) Client-authenticated_TLS_handshake). Beachten Sie, dass SSL per se [Juni 2015] (https://tools.ietf.org/html/rfc7568) zugunsten von TLS veraltet war.
@WarrenT, Ich glaube, er spricht über die Authentifizierung des ** Benutzers ** (des Logins), während Sie über die Authentifizierung der Schnittstelle sprechen.
"SSH hat dann eine Benutzerauthentifizierungsschicht, der SSL fehlt" ist nicht wahr. Sie können den Benutzer mit Zertifikaten oder öffentlichen Schlüsseln in TLS authentifizieren
#3
+13
Halberdier
2013-05-09 21:03:42 UTC
view on stackexchange narkive permalink

Aus strikter kryptografischer Sicht bieten beide eine authentifizierte Verschlüsselung, jedoch auf zwei verschiedene Arten.

SSH verwendet die sogenannte Verschlüsselung und MAC, dh die verschlüsselte Nachricht wird einem Nachrichtenauthentifizierungscode (MAC) der eindeutigen Nachricht gegenübergestellt, um die Integrität zu erhöhen. Dies ist nicht immer vollständig sicher (auch wenn es in praktischen Fällen ausreichen sollte).

SSL verwendet MAC-then-Encrypt: Ein MAC wird dem Klartext gegenübergestellt, dann werden beide verschlüsselt . Dies ist auch nicht das Beste, da bei einigen Blockverschlüsselungsmodi Teile des MAC erraten werden können und etwas auf der Verschlüsselung anzeigen. Dies führte zu Schwachstellen in TLS 1.0 (BEAST-Angriff).

Beide weisen also potenzielle theoretische Schwächen auf. Die stärkste Methode ist Encrypt-then-MAC (Hinzufügen eines MAC der verschlüsselten Nachricht), die beispielsweise in IPsec ESP implementiert ist.

Das binäre Paketprotokoll von SSH ist Encrypt-and-MAC, wobei für jede Klartextnachricht (m) der Chiffretext E (m) ++ MAC (m) (verschlüsselte Nachricht mit MAC verketten) gesendet wird, im Gegensatz zu SSL, das E (m ++ MAC) ausführt (m)). SSH ist jedoch viel mehr als nur das binäre Paketprotokoll (Schlüsselverwaltung, Remote-Shell-Client / Server, Dateiübertragung usw.), während SSL (jetzt TLS genannt) nur das Transportschichtprotokoll ist, das in anderen hinzugefügten Protokollen verwendet wird in der notwendigen Funktionalität (zB HTTPS, FTPS, IMAPS etc.). Siehe auch Vergleich von EtM, E & M, MtE unter: http://crypto.stackexchange.com/questions/202
Völlig einverstanden, gibt es viel mehr als das, was ich geschrieben habe; das meinte ich mit meinem _incipit_ "aus einer streng kryptografischen sicht".
BEAST ist nicht mit MtE verwandt und beruht auf bekanntem IV mit CBC (in SSL3 und TLS1.0) - was SSH2 ebenfalls korrigiert und nicht korrigiert hat, obwohl es als Alternative CTR erhielt, bevor sowohl es als auch TLS AEAD = GCM erhielten(TLS auch CCM) (und beide ChaCha / Poly) als bessere Alternative.Die auf MtE + CBC-Padding basierenden Angriffe sind POODLE und Lucky13.
Ich habe eine Lösung, die MAC-then-Encrypt für jede Verschlüsselung sicher macht, die Ausgabegröße = Eingabegröße und keine schwache Dateneingabe in den Verschlüsselungskern hat.
Diese Antwort ist veraltet, da TLS dies heute nicht mehr tut.
#4
+3
Sam Moore
2015-06-16 02:25:25 UTC
view on stackexchange narkive permalink

Ich denke, es gibt einen Aspekt dieses Vergleichs, der übersehen wurde. user185 kam näher, kam aber nicht ganz dahin. Ich bin damit einverstanden, dass dies Äpfel und Orangen sind und fühle mich besser als Äpfel zu Äpfeln als HTTPS und SSH. HTTPS und SSH verwenden unterschiedliche Schichten des OSI-Modells und verschlüsseln daher die Daten zu unterschiedlichen Zeitpunkten bei der Übertragung. Dann sollten die eigentlichen Fragen lauten, wann diese Daten während der Übertragung verschlüsselt und unverschlüsselt werden. Dadurch werden Ihre potenziellen Angriffsflächen sichtbar. Bei HTTPS wird das Paket, sobald es von einem Gerät im Zielnetzwerk (Webserver, Border Router, Load Balancer usw.) empfangen wurde, unverschlüsselt und verbringt den Rest seiner Reise im Klartext. Viele würden argumentieren, dass dies keine große Sache ist, da der Datenverkehr zu diesem Zeitpunkt intern ist. Wenn die Nutzdaten jedoch vertrauliche Daten enthalten, werden sie unverschlüsselt in den Protokolldateien jedes Netzwerkgeräts gespeichert, das sie durchlaufen, bis sie zu ihren Daten gelangen Endstation. Bei SSH wird normalerweise das Zielgerät angegeben und die Übertragung wird verschlüsselt, bis es dieses Gerät erreicht. Es gibt Möglichkeiten, die HTTPS-Daten erneut zu verschlüsseln. Dies sind jedoch zusätzliche Schritte, die die meisten vergessen, wenn sie eine HTTPS-Lösung in ihrer Umgebung implementieren.

#5
+1
datsusarachris
2015-01-19 21:17:45 UTC
view on stackexchange narkive permalink

ssh ist wie ein Schlüssel (privat) und das Schloss (öffentlich)

ssl ist wie die Tür und die Ziegel.

ssl bietet eine sichere Verbindung zwischen den beiden Computerservern . z. B. Ihre und die, mit der Sie eine Verbindung herstellen.

ssh ist, wie der verbindende Computer sich selbst überprüfen und Zugriff erhalten kann.

Sie erklären den Kommentar "Tür und Ziegel" überhaupt nicht.SSL hat auch öffentliche und private Schlüssel.SSL kann auch zur Clientauthentifizierung verwendet werden.SSH bietet auch eine sichere Verbindung zwischen dem Client und dem Server.
#6
  0
Gobbly
2014-08-05 03:52:56 UTC
view on stackexchange narkive permalink

SSL ist eine Protokollschicht, die vom zu tunnelnden Inhalt abstrahiert wird. SSH ist eine sichere Version von Shell (SH). Es wurde nicht entwickelt, um eine abstrakte Ebene darunter zu enthalten. Es wurde speziell für den Transport von Shell-Verkehr entwickelt. Obwohl in beiden Fällen Kryptooperationen verwendet werden und diese Kryptooperationen sogar gleich sein können, ist der Zweck und das Gesamtdesign daher sehr unterschiedlich.

Beachten Sie, dass es spezifische Unterschiede gibt (wie oben erwähnt) ), aber die meisten, wenn nicht alle dieser Unterschiede beruhen auf dem Zweck der verschiedenen Protokolle.

-1 Sie gehen fälschlicherweise davon aus, dass OP SSL mit dem Unix-Programm [ssh (1)] vergleicht (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1) ). SSH ist eigentlich ein weiteres Protokoll, das Sicherheit auf Transportschicht bietet und besondere Bestimmungen für Remote-Shells und Remote-Ausführung enthält.
#7
-1
Stanley Hutchinson
2013-12-13 05:19:22 UTC
view on stackexchange narkive permalink

Das Problem ist zweifach, es ist nicht nur die Stärke und Schwäche der Verschlüsselung. Aber es ist die Leichtigkeit und Bequemlichkeit der Lieferung. Aus geschäftlicher Sicht ist SSL / TLS daher bequemer und einfacher, da nur ein Browser und entweder ein öffentliches oder ein privates Zertifikat erforderlich sind.

Für SSH muss entweder die Anwendung oder der Thin Client installiert sein. Dies ist aus Sicht des Internet-Clients und des Supports eher ein Problem.

#8
-1
Deep
2018-01-04 21:23:11 UTC
view on stackexchange narkive permalink

Wenn Sie wirklich nach SSH vs SSL (TLS) suchen, lautet die Antwort SSH.

Ein Grund, warum SSH SSL gewinnt, ist die Art und Weise, wie die Authentifizierung durchgeführt wird. Aus diesem Grund verwenden Sie bei Verwendung von FTP das SSH-Protokoll (SFTP) anstelle von FTPS (FTP über SSL).

SSH wird in Unternehmensnetzwerken verwendet für:

  • Bereitstellung eines sicheren Zugriffs für Benutzer und automatisierte Prozesse
  • interaktive und automatisierte Dateiübertragungen
  • Ausgabe von Remote-Befehlen
/ blockquote>

Quelle: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

"Aus einem Grund gewinnt SSH SSL durch die Art und Weise, wie die Authentifizierung durchgeführt wird." Haben Sie eine Quelle oder eine Erklärung für diese Behauptung?
In SSH gibt es zwei Möglichkeiten, den Server zu verbinden.Bei der schlüsselbasierten Authentifizierungsoption müssen Sie zunächst einen privaten und einen öffentlichen SSH-Schlüssel generieren.Welches ist nicht viel zusätzliche Arbeit.Dies gilt auch für bewährte Sicherheitspraktiken.SSL hat so viele Versionen, dass die neueste Version TLS1.2 ist.Das heißt, es ist noch nicht so sicher, aber im Prozess, um besser zu werden.
TLS verfügt auch über clientseitige Zertifikate.Sie erklären nicht, warum SSH "gewinnt".
Wenn Sie von irgendwoher kopieren / einfügen möchten, stellen Sie sicher, dass Sie Ihre Quelle angeben.
"SSL hat so viele Versionen" Also sind 6 Versionen "so viele"?OpenSSH ist auf Version 7.7."Das heißt, es ist noch nicht so sicher, aber im Prozess, um besser zu werden."Ihre Logik macht hier keinen Sinn.
Ich kann TLS und eine REST-API verwenden, um alles auf Ihrer Liste zu erledigen, und tatsächlich werden auf diese Weise viele Verwaltungsfunktionen jetzt behandelt.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...