I am trying to use .NET implementation of SslStream by this tutorial.
I did everything like in this article, but I have some question. I downloaded RawCap and captured packets from the localhost, after that I opened dump file(.pcap) using Wireshark, but instead of SSL or TLS type of protocol, I saw just TCP: Here is the part of the TCP stream:
....l...h..T...........Y.2..1...t.4....8.J...../.5...
.......
.2.8.......'..............SslServer.
......................M..T...M.<.......e.E...M.%c...Kg.. .....iKku.^q(C.$..;..Mx......g&./..................0...0.............L.^..F.)...{.0...+......0.1
0...U....MyCA0..
150228143257Z.
391231235959Z0.1.0...U....SslServer0.."0
..*.H..
..........0..
......p9.cq...F.^....Bm...S... .....Bg.B.<]..f[...<...q'..Tc......R...Z.C.D.D...N...1..0.v..l.<...d[=C.7.8.+^..j(...X.........D'.!*5.^.^Ef..=.6y#.=..)|...Sp..Sv.|h.-..UT..&bG.......J{.7k.X...........:.[o....o.,r.......0..Wi.s..8.Jn9........4...WU....fkmw..........D0B0#..U...907..m.....#..
...f...0.1
0...U....MyCA..(J..j+..K......0...+...........h..X.+.M..{...n.....#.'.F........~....#9J.......A4,>.9.DE.R.V4t._bGY.,v.>G......J ....3....#..c,%[S._..u...$....!V.r....~...'.~..T*[.#[.?.B{..Z..m.p.9.7.U.u.}.e..c..H^n.:...-AJxs.. ...:...
..u.....YB....2n...y.g=...(.Fv...B.Is..GK.....;.F..Ln.....L...ao
......#...q0o1.0...U....SE1.0...U.
..AddTrust AB1&0$..U....AddTrust External TTP Network1"0 ..U....AddTrust External CA Root..0..1.0...U....US1.0...U.
.
GeoTrust Inc.1907..U...0(c) 2008 GeoTrust Inc. - For authorized use only1604..U...-GeoTrust Primary Certification Authority - G3.g0e1.0...U....US1.0...U.
Is this correct SSL/TLS stream? And why Wireshark marked it like TCP?
UPD:
By default Wireshark uses TCP port numbers to know if this is standard TCP or TLS/SSL.
If you want to make Wireshark permanently recognize any port as SSL/TLS, then go to Edit > Preferences > Protocols > HTTP > Under SSL/TLS Ports change it from 443 to 443,5555, ... <other TLS/SSL ports go here>.
Also note that SSL traffic is encrypted, and that is why you won't be able to see the actual data being transmitted. If you want Wireshark to decrypt SSL traffic, then you will have to give it your server's private key (reference SSL dissection in Wireshark)
Related
I have a pcap file with has the TLSv2.0 traffic from an Windows exe application.
I also have the backend server's private key used to establish the connection.
I have tried both the enabling ssllogfile environment variable and also tried selecting the private key under Wireshark -> Preferences -> TLS. But I still could not decrypt the traffic.
Is there any other way?
The cipher suite used is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
The "ECDHE" means the key exchange is done using Elliptic Curve Diffie-Hellman, which provides forward secrecy. This means that the private key from the server X.509 cert is not enough to decrypt the traffic. You will need to get the client application to generate an SSLKEYLOGFILE, which can be done with Chrome, Firefox and curl. If the "Windows exe application" is something different, then you'll have to intercept the TLS traffic in order to see what goes inside the TLS tunnel.
If you wanna analyze the decrypted traffic in Wireshark, then I'd recommend to proxy the traffic with PolarProxy, because it generates a PCAP file with the decrypted traffic from the TLS session. You will not need any SSLKEYLOGFILE if you choose to intercept and decrypt the TLS traffic with PolarProxy.
I write raw HTTPS client in C - a program that takes domain name, resolves it to IP address (via DNS), connects to the IP address on port 443 (SSL), performs SSL handshake and then sends HTTP request via the SSL socket.
To try this program I have a domain hosted on a webserver. I installed Let's encrypt certificate for the domain.
I found out that there are many domain names sharing the same IP address as my domain. So when I connect to the IP address on port 443 to perform SSL handshake who ensures that mydomain's SSL certificate will be sent from the server to the client and not another certificate belonging to other domain name sharing the same IP address?
There exists a TLS extension called Server Name Indication (SNI) which is widely used (and is e.g. require for http/2 clients). You can find the formal specification of this extension in RFC 6066.
Using SNI, a client can send a desired hostname in its Hello request which allows the server to select a matching key/certificate combination for this connection.
DNS traffic (requests and responses) has been encrypted by DNSCrypt. In this case, is hostname (https://www.example.com /destination IP adress) readable in transit by a third party during my TLS session? Actually i would like to clarify what does make hostname visible to others - unencrypted DNS traffic only or both unencrypted DNS and initial request to the destination server in the TLS session context?
The hostname is part of the Server Name Indication (SNI) extension of the TLS handshake. When this extension is used it is send in clear inside the ClientHello part of the handshake. All current browsers use SNI.
Apart from that the hostname is usually part of the servers certificate. The certificate is also send in clear by the server during the SSL handshake.
Which means DNSCrypt only protects the DNS lookup and nothing more.
BTW, a better forum for such kind of questions is security.stackexchange.com.
I have Local Webserver that configured to use SSL connection.
The question is - would there be any handshakes if i try to open https://localhost from any browser?
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys. But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
So, does handshake really happens, but on the upper OSI level? Or it doesnt happen at all, and there are no derive key creation?
Would there be any handshakes if i try to open https://localhost from any browser?
Yes,
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys.
No. It requires a certificate, and a premaster secret, and mutual negotiation of a master key from which session keys are derived. All this is irrelevant.
But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
Wireshark can't see loopback packets.
So, does handshake really happens
Yes.
but on the upper OSI level?
SSL happens in the application layer of the TCP model. The OSI model does not apply to TCP/IP. TCP/IP has its own model.
Or it doesn't happen at all
It does.
and there are no derive key creation?
There is creation of a pre-master secret, a master secret, and a session key. You seem to have some misconception of this process, but again it isn't relevant.
I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.
If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message
Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.
Here's what I've done :
I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)
I've registered my HTTP port like this :
httpcfg delete ssl -i 0.0.0.0:443
httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...
Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.
Now, the following will timeout :
Microsoft Telnet> open localhost 443
Here's the output from netstat (The Pid '4' is the 'System' process):
netstat -nao
Proto Local Adress Remote Adress State Pid
TCP 0.0.0.0:443 0.0.0.0:0 Listening 4
And here's a screenshot from TCPView captured when I issued the open command in telnet :
alt text http://img26.imageshack.us/img26/3376/tcpview2si6.jpg
I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)
So far I've tried to :
Redo all the steps from scratch following exactly the MSDN tutorial
Used port 10443 instead of 443
Disable the firewall
Use a self signed certificate
I don't know what to try next .. any ideas?
The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.
The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.
You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.
Telnet cannot be used to comunicate with encrited webs.
Checkout this microsfot note. It says "NOTE: This example assumes that the Web server is configured to use the default HTTP port (TCP 80). If the Web server is listening on a different port, substitute that port number in the first line of the example. Also, this example does not work properly over an HTTPS/SSL connection (TCP 443, by default), because the telnet client cannot negotiate the necessary encryption commands to establish the SSL session. Although an initial connection is possible over the HTTPS/SSL port, no data is returned when you issue a GET request."
Update: Checkout this other note HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server or on an Intermediate Device
As FerrariB said, telnet does not perform the negotiations necessary to open an SSL connection. Telnet knows nothing about certificates, nor encryption. Thus, you are guaranteed to not be able to communicate with HTTPS port 443 via telnet. You will have to find another way to do whatever you are trying to do.
Check out the Wikipedia page on TLS for example, where it says directly:
If any one of the above steps fails, the TLS handshake
fails, and the connection is not created.
This is precisely what you are seeing by trying to use telnet to communicate with an SSL endpoint.
in command prompt: netstat -nao |find "443"
the last columns show a number:
pic no.1
Now open task manager.find result number in 1st section in pid column (if pid wasn't enabled, choose it from view tab) program name show the program which uses the port.
disable the program that uses the port /in my case I stopped it from services