Datenaustausch Webserver => Browser

Hallo Leute,

ich beschäftige mich grad bisschen mit der WebProgrammierung bzw. vorallem mit dem Datenaustausch zwischen Webserver und Client(Browser).

Nun WebClients fragen ja generell irgendwelche Daten/Ressourcen auf dem Webserver an, der Webserver ist ja ganz "allgmein" betrachtet nur ein Fileserver, der Daten in form von Files (html/jpgs/json,....) an den Client auf anfrage überträgt. Richtig!?

Die Verbindung zum Webserver ist ja nur flüchtig, d.h. nach eine Anfrage vom Client wird die Verbindung bzw. Socket wieder gschlossen! Richtig? Das gleiche gilt auch für Polling mechanisment für dynamische Seiten (bspw. axja) da wird , ja für jede Datenanfrage von Ajax eine Verbindung geöffnen und wieder geschlossen! Richtig?

Was steckt hinter WebMethoden? Da werden ja Daten angefragt mit best Parameter (im Link bspw: .../mysite.html&par1=edit&par2=true&par3=true) oder? diese werden als Methoden paramter interpetiert und entsprchend daten zurückgeliefert?

Danke schonmal Nette Grüße
Wie sieht es mit Streamen aus, kann ein client auch einen "verbindungsorientierte" Kanal aufm machen , und ja in welchen Technologien wird das verwendent?

Wie sieht es bei SSL/Https aus? Schickt da der client daten in verschlüsselte form, und der webserver entschlüselt die ankommenden daten erst mal und verarbeitet sie und gibt sie verschlüsselt wider zudrück? Ganz auf tcp ebene?

Jodocus

Nun WebClients fragen ja generell irgendwelche Daten/Ressourcen auf dem Webserver an, der Webserver ist ja ganz "allgmein" betrachtet nur ein Fileserver, der Daten in form von Files (html/jpgs/json,....) an den Client auf anfrage überträgt. Richtig!?

Außer, wenn man ihn dazu nötigt, Programme auszuführen (d.h. entweder Scripts wie PHP, Python, etc. oder Binaries über CGI/DLLs/whatever). Die werden dann, neben anderen Dingen, die sie so tun, auch wieder Hypertext generieren, den du dann zu Gesicht bekommst. Der Webbrowser weiß am Ende nichts davon, der weiß sieht nur den Typ der Daten (nennt sich MIME-Type) und stellt die dar.

Die Verbindung zum Webserver ist ja nur flüchtig, d.h. nach eine Anfrage vom Client wird die Verbindung bzw. Socket wieder gschlossen! Richtig?

Eher nicht. Meistens wird im HTTP-Header Connection: keep-alive vereinbart. Wenn man Sachen wie Bilder noch nachladen möchte, wäre es recht unklug, jedes mal von vorne die Verbindung aufzunehmen.

Zum Rest: Wie wäre es mal mit Google? Ist nicht so, dass man im Web nichts zum HTTP findet.

Danke für die Antworten,

aber noch eine Frage:

wenn der Client "Keep-alive" im http header hat, dann soll der WebServer den Socket für die Verbindung nich schliessen! Gut! Aber woher weiß der Server wenn er den Socket wieder schliessen kann? Deswegen habe ich gefragt:)

Grüßle

Marc-O

Hallo

Und deine Frage zu beantworten müsstest du nur nach http Protokoll suchen. Hier die erste Antwort dazu http://de.m.wikipedia.org/wiki/Hypertext_Transfer_Protocol.

Und zu deinem Jeep Alice, die Verbindung wird vom Client geschlossen und des merkt der Server und schließt ebenfalls seine Verbindung.

Grus Marco

hustbaer

In der Praxis kann der Server die Verbindung jederzeit schliessen, einfach wenn er meint dass es ihn nicht mehr freut noch länger zu warten.
Weiss zwar nicht ob das der Standard erlaubt, aber real muss jeder Client damit klarkommen.

Servus Jungs,

Danke für die Infos! Allerdings weiß ich nicht mit welchem "Parameter" (im Http Header), der vom Client den SErver informiert dass er die Verbindung schliessen kann! Oder ich habs übersehen!?

Wie siehtes mit HTTPS aus, hab da bisschen recherchiert, und ein Client baut eine HTTPS verbindung auf, in dem er im normalen HTTP Header via CONNECT einen Tunnen bzw. zweiten socket auf macht richtig!? Des weiteren konnte ich keine Konkrete Antwort finden wie das HTTPS-Header aussieht, da sind die Leute geteilter meinung, das einmal der Header komplett verschlüsselt ist, oder nur ein Teil davon!

Wie ist das dann generell, bzw. was wird unter dem Tunnel verstanden!?
Der Client schickt anfragen also eine verschlüsseltes (SSL) HTTP Header ,und
Der Server schickt bspw. eine HTML Dokument verschlüsselt zurück!?

HAbe im Netz noch kein easy Sequenzdiagram gefunden, das den aufbau eine HTTPS verbindung beschreibt!?:)

Grüße und schöne WE;)

Noch was:)

wenn ich einen HTTPS Request an einen WebServer mache, dann ist das ankommen HTTP Header schon veschlüsselt, aber wohe weiß dann der WebServer mit welchem Key die der Header veschlüsselt ist!?!?
Da dies das Datenpacket ist, dass der Client schickt frag ich mich, wie die gemeinsamen schlüssel ausgetauscht werden!?!

Danke:)

TyRoXx

NullBockException schrieb:

wenn ich einen HTTPS Request an einen WebServer mache, dann ist das ankommen HTTP Header schon veschlüsselt, aber wohe weiß dann der WebServer mit welchem Key die der Header veschlüsselt ist!?!?
Da dies das Datenpacket ist, dass der Client schickt frag ich mich, wie die gemeinsamen schlüssel ausgetauscht werden!?!

TLS definiert ein Protokoll, um genau das auszuhandeln, bevor Nutzdaten verschlüsselt ausgetauscht werden.

Hallo Danke,

aber das is mir Bewußt (glaub ich zumindest)!

Es geht ehr darum, wenn ich einen einfache TCP Server habe!
und von diesem eine Fiktive Seite wie

https:\\localhost:5050\Index.html

abfrage, kommt eine verschlüsseltes Datenpaket an. Nun frage ich mich mit welchem Schlüssel diese Verschlüsselt wurde, es sind ja keine Zertifikate ausgetausch wurden etc. die für diese fiktive Seite verwendetn werden solln.

Anders bei HTTP also

http:\\localhost:5050\Index.html

kommt eine
HTTP Header an lesebar im ASCII Format an!

Aber bei HTTPS is diese halt bei der ersten Datenaustausch schon verschlüsselt, und ich frage mich was der schlüssel dahinten ist.. egal ob SSL oder TSL..

Grüßle

nman

Slashes, nicht Backslashes.

TyRoXx hat deine Frage schon beantwortet. Wenn du nach "TLS key exchange" oä. googelst, ist der erste Treffer das hier:

http://security.stackexchange.com/a/8348

Deine Fragen lassen sich per Google _wirklich_ leicht beantworten.

Jodocus

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;)

Jodocus

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 stellen

Bitte 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

https://localhist:8080/

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();
            }
        }

Shade Of Mine

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

Shade Of Mine

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!

Shade Of Mine

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 number

2. Server antworte mit "HelloClient":

-SSL Protocol Selected
-SessionID
-Selected Cipher Suite
-Selected Compression Method
-Random Number

3. 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]

Datenaustausch Webserver =&gt; Browser

Datenaustausch Webserver => Browser