Datenaustausch Webserver => Browser
-
Ich habe fast das Gefühl, dass ich auf Blurry reingefallen bin.
-
Nein Bist du nich Jodocus:)
Wie war das : "Es gibt keine blöden Fragen nur blöde Antworten" :p
Mir ist gerade erst bewußt geworden, dass es es einen privaten und öffentlichen
Key ist, und der private Key ist wohl in dem https header drine.. dieser reicht
wohl um den https header zu entschlüsseln...Aber vll. lieg ich auch falsch.. Ich habe mich wohl noch nich genug mit
den Verschlüssungvefahren informiert, um eine frage zu https zu stellen
Bitte seid gnädig:)
Schönen sonntag euch;)
-
NullBockException schrieb:
Nein Bist du nich Jodocus:)
Wie war das : "Es gibt keine blöden Fragen nur blöde Antworten" :p
Die Fragen sind nicht blöd, aber es ist blöd, sie hier zu stellen. Die Antworten gibt es bereits tausendfach im Netz zu lesen. Alles, was du dafür brauchst, ist ein Quäntchen Eigeninitiative.
NullBockException schrieb:
Mir ist gerade erst bewußt geworden, dass es es einen privaten und öffentlichen
Key ist, und der private Key ist wohl in dem https header drine.. dieser reicht
wohl um den https header zu entschlüsseln...Aber vll. lieg ich auch falsch.. Ich habe mich wohl noch nich genug mit
den Verschlüssungvefahren informiert, um eine frage zu https zu stellenBitte seid gnädig:)
Schönen sonntag euch;)
Asymmetrische Verschlüsselung ist ein ganz anderes Thema. Ich würde dir dennoch mal vorschlagen, dass du einfach alle Themen, die dich so interessieren mal in einem Lexikon nachschlägst (bzw. Wikipedia heutzutage) und danach Fragen stellst, falls du darin etwas nicht verstehst, okay?
-
Ich (glaube) ich habe gefunden was ich wollte:)
https://www.simple-talk.com/dotnet/.net-framework/tlsssl-and-.net-framework-4.0/bin dabei "spasshabler" einen kleinen mini webserver zu programmieren der so die https basics kann, wollte eben dass diese https unterstütz , das is euch ein gute artikel.. hift mir viel;)
Danke euch allen mal:)
-
So Jungs,
folgendes, ich hab mir den Code aus der MSDN seite gekaut. Habe eine Test Certificat erstellt! dem server mitgeben. alles cool!
https://msdn.microsoft.com/de-de/library/system.net.security.sslstream%28v=vs.110%29.aspx
Danach habe ich mich mit dem IE auf denn server verbunden
Danach Frägt mich der Browser die standard Frage ob die Seite seriös ist!
Wenn ja verbindet er sich (certifikate werden ausgeschaut nehmen ich an)Dann wird ein Text zum browser geschickt! Und die verbindung geschlossen. So weit so gut!
https verbindungen werden ja nich geschlossen oder ? Der datenaustausch auf der gesamten seite findet nun mit dem offenen SslStream statt richtug? Ich habe das noch nich so richtig verstanden
public static void RunServer(string certificate) { serverCertificate = X509Certificate.CreateFromCertFile(certificate); // Create a TCP/IP (IPv4) socket and listen for incoming connections. TcpListener listener = new TcpListener(IPAddress.Any, 8080); listener.Start(); while (true) { Console.WriteLine("Waiting for a client to connect..."); // Application blocks while waiting for an incoming connection. // Type CNTL-C to terminate the server. TcpClient client = listener.AcceptTcpClient(); ProcessClient(client); } } static void ProcessClient (TcpClient client) { // A client has connected. Create the // SslStream using the client's network stream. SslStream sslStream = new SslStream( client.GetStream(), false); // Authenticate the server but don't require the client to authenticate. try { sslStream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Tls, true); // Display the properties and settings for the authenticated stream. DisplaySecurityLevel(sslStream); DisplaySecurityServices(sslStream); DisplayCertificateInformation(sslStream); DisplayStreamProperties(sslStream); // Set timeouts for the read and write to 5 seconds. sslStream.ReadTimeout = 5000; sslStream.WriteTimeout = 5000; // Read a message from the client. Console.WriteLine("Waiting for client message..."); string messageData = ReadMessage(sslStream); Console.WriteLine("Received: {0}", messageData); // Write a message to the client. byte[] message = Encoding.UTF8.GetBytes("Hello from the server.<EOF>"); Console.WriteLine("Sending hello message."); sslStream.Write(message); } catch (AuthenticationException e) { Console.WriteLine("Exception: {0}", e.Message); if (e.InnerException != null) { Console.WriteLine("Inner exception: {0}", e.InnerException.Message); } Console.WriteLine ("Authentication failed - closing the connection."); sslStream.Close(); client.Close(); return; } finally { // The client stream will be closed with the sslStream // because we specified this behavior when creating // the sslStream. sslStream.Close(); client.Close(); } }
-
Setz dich hin. Lies dir durch wie HTTP und TLS funktioniert. Schau dir einen der 100 millionen fertigen Code Snippets an und dann überlege dir deine Frage.
Was genau funktioniert nicht? Was genau erwartest du dass passiert? Was genau passiert? Oder hast du ein generelles Verständnis Problem?
-
Ich hab ein generelles Verständnis Problem!
Es ist ja nich so, dass ich nich recherchiere!
Ich habe auch verstanden wie HTTP funktioniert (ohne TSL Tunnel).Mein bisheriges Verständnis:
HTTP Verbindungen sind flüchtige Verbindungen: Client fragt an=> Server erzeugt
Socket => verarbeiet den HTTP Request => Schickt Response=> schliesst Socket wieder. (Habe ich auch schon ein mini WebServer gemacht der simple Anfragen eines Broweser verbeiten kann.)Nun zu HTTPS: Client Request und Server Responsen werden in einer "stehenden"
Verbindung gehandelt!? Also quasie in dem SslStream wie in dem Beispiel!Also jetzt meine Verständnis Problem Frage:
Nehmen wir an einen Browser macht eine Anfrage (https://...) an (meinen) WebServer! Dann tauschen ja Browser und und mein WebServer mit:
SslStream sslStream = new SslStream( client.GetStream(), true); // Authenticate the server but don't require the client to authenticate. sslStream.AuthenticateAsServer(_serverCertificate, false, SslProtocols.Tls, true);die Verschlüssungsmethoden aus!? Richtig? Danach habe ich einen Stream, und alle Anfragen des Clients die sich auf den Host (Server) "https://localhost:666/" beziehen finde auf dem Stream statt! Hab ich das richtig verstanden??
Wenn ich nun eine Datei vom Server haben will "https://localhost:666/Resource.bla" dann mach ich das über den selben Stream,
oder wird da wieder eine neuer Tsl Handschake gemacht und neue Verbindung + SslStream aufgebaut!? Das hab ich nich gerafft!Des weiteren habe ich ein Test Zertifikat also .pfx, und .cer generiert und installiert (unter Vertrauenswürdige Zertifikate). Dann müssten diese ja auch in meinem Browser auf localhost ja bekannt sein, werden aber in den Browser abgewiesen ..
Sorry, falls es euch aufn Sack geht, aber habe da einfach noch große lücken
-
Wieso denkst du dass HTTPS Grundlegend anders ist als HTTP?
Du kannst bei Beiden (bedenke, HTTPS ist nichts anderes als ein HTTP durch einen TSL Tunnel) sowohl ein keep alive als auch ein connection close haben.
Du kannst immer ein connection close machen wenn das einfacher für dich ist. keep alive wurde nur aus Performance Gründen eingeführt.
Wenn du eine keep alive Verbindung hast, dann steht die Verbindung natürlich und du macht alle Requests darüber (kein neuer Handshake). Ein Handshake findet ja nur beim Aufbau einer Verbindung statt.
Hast du eine konkrete Frage?
Ob Zertifikate vertrauenswürdig sind, ist ein komplett anderes Thema und hängt hauptsächlich von deiner Konfiguration ab. Ignoriere das Thema vorerst.
-
Hallo Shadow,
ich hab eben aufgeschnappt, dass HTTPS eine ständig stehende Verbindung ist. Und habe so assoziiert , dass ich über meinen SslStream via Read und Write die Request und Response abarbeite! Ok Gut, dann hatte ich da wohl das falsche Verständnis!
Nun noch ne Frage zu den Zertifikaten! Ich habe ja eine Eingen Dummy Zerfitifkat er zeugt mit : makecert.exe und pvk2pfx.exe! Danach habe ich das Zertifikat in Windows installiert! Und das sehe ich auch im CertMrg!
Gut und schön!
Nun starte ich meinen WebServer (siehe Code von MSDN) Dieser bekommt meine ".Cer" Datei. Nach dem Sich dann mein Browser (in meinem Fall der IE) verbindet, wird er Handshake durchgeführt.. und mein Browser melde:
Es besteht ein Problem mit dem Sicherheitszertifikat der Website.
Das Sicherheitszertifikat dieser Website wurde nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt.
Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt.
Die Sicherheitszertifikatprobleme deuten eventuell auf den Versuch hin, Sie auszutricksen bzw. Daten die Sie an den Server gesendet haben abzufangen.
Es wird empfohlen, dass Sie die Webseite schließen und nicht zu dieser Website wechseln.
Symbol für empfohlenKlicken Sie hier, um diese Webseite zu schließen.
Symbol für nicht empfohlenLaden dieser Website fortsetzen (nicht empfohlen).
Und der SSlStream wird geschlossen! Mein Problem ist jetzt, wieso mein Zerifikat nich gütlig ist, das is auf der selben Maschine installiert wo der Server und mein Browser läuft!
Wenn ich nun im Browser "Laden dieser Website fortsetzen (nicht empfohlen). " klicke,
bekomme ich eine IOException bei meinem SslStream:
Von der Übertragungsverbindung können keine Daten gelesen werden: Eine vorhandene Verbindung wurde vom Remotehost geschlossen.
Das is mein Konkretes Problem bzw. die Frage!
-
Das ist eine andere Frage die du in einem anderen Thread klären solltest. Ich habe unter Windows noch nie SSL Zertifikate erstellt - ich mache das immer über OpenSSL.
Dann gibt es auch unterschiedliche Zertifikathandhabungen. Je nach Browser wird die vom System oder eine Browser eigene verwendet.
uU ist das Zertifikat ja auch falsch ausgestellt worden.
Du kannst auch deinem Browser einfach sagen dass er dem Zertifikat trauen soll.
Das ist generell aber kein Programmierproblem.
-
Hallo Leute, jetzt MUSS ich doch nochmal nachhaken .. der SSL-Handshake zwischen server und client!
1. Client schickt an eine Server eine "HelloServer":
-Max SSL Protocol version allowed
-SessionID
-Set of Cipher Suites
Set of Compression Methods
-Random number2. Server antworte mit "HelloClient":
-SSL Protocol Selected
-SessionID
-Selected Cipher Suite
-Selected Compression Method
-Random Number3. Danach der Zertifikat austausch!
So aber was ich einfach nich verstehen will ist:
Der client beginnt das Handshake, und schickt dieses in "verschlüsselter" Form!
WOHER weiß der client zu diesem Zeitpunkt wie das Telegram "HelloServer" verschlüsselt sein muss, damit der Server das versteht!? Beide wissen zu diesem Zeitpunkt ja noch nich den gemeinsamen Schlüssel!!Wenn ich jetzt jene x-belibige webseite via https öffne, kenn der browser ja nich den schlüssel mit dem der server auf der anderen seite entschlüsselt!
Und schickt trozdem ein verschüsseltes telegram. Wie geht das?siehe :
[url]https://www.simple-talk.com/dotnet/.net-framework/tlsssl-and-.net-framework-4.0/
[/url]
-
Das kannst du im Internet easy nachlesen. Aber SSL/TLS ist natürlich jetzt nicht sonderlich Anfängerfreundlich. Es ist eine komplexe Sicherheitsinfrastruktur.
Vielleicht willst du dir einfach mal eine gute Beschreibung durchlesen wie das abläuft oder aber du akzeptierst es als Blackbox. Da die genauen Vorgänge ja eh irrelevant für dich sind.
Der SSL Handshake beginnt aber ohne Verschlüsselung. Das ist die Idee eines Handshakes. Sobald der Handshake beendet ist, ist die Verbindung verschlüsselt. Der Tricky Part an dem ganzen ist natürlich einen Handshake zu machen der auch wenn er mitgesnifft wird dennoch eine sichere Verschlüsselung garantiert.
Welche Verfahren SSL hier verwendet weiß ich zB gar nicht. Du kannst dir aber mal Diffie Hellman ansehen. Das ist ein simpler Handshake Algorithmus der dennoch recht sicher ist. Wenn du ihn verstanden hast wirst du die Verfahren verstehen mit denen SSL arbeitet.
Aber wie gesagt: wenn es dich interessiert, lies nach. Gibt massig Doku zu dem Thema. zB hier von Microsfort: https://support.microsoft.com/kb/257591/de
Wenn du dich bei dem Thema aber nicht auskennst ist SSL/TLS einfach der falsche einstieg. Das ist ein hochkomplexes System dass stark parametisierbar ist und viele Features hat die für ein einfaches Verständnis eines Verschlüsselungsverfahren einfach nicht notwendig ist.
Abgesehen davon ist SSL/TLS auch sicher nicht das schönste Studienobjekt, da es eine Menge altlasten mit sich schleppt.
-
Hey Shade,
danke für die Antwort:) Generell soll TSL bzw. SSL auch eine Blackbox bleiben, was da passiert is mir egal, hautpsache ich hab nen verschlüsselten stream:)
Ich hab nur gefragt, weil ich eben die Anfrage des Clients an den Server in meiner server Anwendung (wenn der handshake beginnt) nicht in plain-text sehe, sonder ein bytehaufen. Deswegen dachte ich zuerst: "hää verschlüsselte daten, woher kenn der server den schlüssel um sie zu entschlüsseln"
Aber die daten sind wohl bei dem ersten Datenaustauch nich verschlüsselt , sonder einfach nur binär codiert... deswegen war ich irritiert:)
Danke :))
-
NullBockException schrieb:
Ich hab nur gefragt, weil ich eben die Anfrage des Clients an den Server in meiner server Anwendung (wenn der handshake beginnt) nicht in plain-text sehe, sonder ein bytehaufen. Deswegen dachte ich zuerst: "hää verschlüsselte daten, woher kenn der server den schlüssel um sie zu entschlüsseln"
Ich kann dir da empfehlen Wireshark zu installieren und dir die Sachen so genau anzusehen.
-
Danke für den Tipp Shade:)