created a webserver(http port 80, https:443) and proxy server(http 8080,https:8081)
am seeing issue when I access proxy over https like
https://xyz:8081/
wireshark shows client(fireforx or chrome) is sending certificate data in HTTP packet , I see certificate text .
Any idea what could be wrong ? browser says no data received
If TLS session is already established(https webserver) would another TLS sessions is created if I try to access https proxy ?
I created SSL socket like
ctx_init
put the socket on select and did accept/sslaccept once I get
and then did SSL_Read
NB: Rest all access like http/https to webserver or http to proxy server works fine.
Updates: Issue was client was sending fragmented HTTP request
So for a GET request it was sent by client like this
Packet 1 was GE
Packet 2 was rest T ....\r\n\r\n
So in code I have to collect until until full HTTP packet is received
Related
I am trying to send out a WebRequest request like https://identityserver.github.io/Documentation/docsv2/advanced/clientCerts.html specifies with a handler containing the Client Certificate.
I've gotten to the point that i have determined that the ClientCertificate is just not being sent through fiddler, so it is not read in the ServerVariables["CERT_FLAGS"] when the Owin LoadCertificate is called.
So i have removed all the steps from the process except (IdentityServer3.Samples/source/Clients/ClientCertificateConsoleClient/Program.cs)
async Task<TokenResponse> RequestTokenAsync()
{
var cert = new X509Certificate2("Client.pfx");
var handler = new WebRequestHandler();
handler.ClientCertificates.Add(cert);
var client = new TokenClient(
Constants.TokenEndpoint,
"certclient",
handler);
return await client.RequestClientCredentialsAsync("read write");
}
but I am still not seeing in fiddler in the raw request the certificate. I have looked at the source code for HttpWebRequest and only see it handles the ClientCertificate in the GetConnectionGroupLine, and then its a hash code which i also don't see in fiddler. I'm working with Windows 7 and i have turned on the iis client certificate mapping authentication and enabled the setting in iis express applicationhost in the 2015 .vs subfolder and the primary one in my docuemnts. What am I missing here?
reference: https://social.msdn.microsoft.com/Forums/en-US/f88a23f2-3dbe-4202-baf2-a5b05b027fe6/httpwebrequest-not-sending-client-certificate-to-server?forum=netfxnetcom
https://github.com/IdentityServer/IdentityServer3/issues/3220 - can't really find this on stackoverflow..
TLDR: Your problem (at this point) is Fiddler not HttpWebRequest/dotnet. (Edited to clarify.)
Fiddler doesn't display TLS info including certs. Fiddler works on, and displays in numerous formats, the HTTP-level data (requests and responses, including application data). When HTTPS transports this HTTP data over SSL/TLS, Fiddler does not display the SSL/TLS-specific data, which in addition to server and optional client certificates (currently) includes version, suite, possibly compression, curve, format and next-protocol negotiation, nonces, ephemeral keys, renegotiation control, signature algorithm control, server name indication, ticket, and other crypto options like encrypt-then-mac and extended-master-secret. The "raw" tab displays all the HTTP data without interpretation, but not the SSL/TLS data.
Fiddler doesn't request client auth. An SSL/TLS session uses a client certificate to perform client authentication only when requested by the server, and when your client connects to the real IdentityServer it presumably requests this. But when Fiddler is used, there is one SSL/TLS session from the client to Fiddler, and an entirely separate SSL/TLS session from Fiddler to the server. On the session from your client to Fiddler, Fiddler does not request client authentication, so your client doesn't and can't send or use its certificate.
Client auth can't be relayed anyway. If Fiddler did request client auth on the session from your client, it couldn't use that information to authenticate the session to the real server. Client auth doesn't just send the client cert, it also uses the private key to sign the concatenation (called a transcript) of the handshake messages. Since the handshake between your client and Fiddler and between Fiddler and the server are quite different, this signature is invalid for the server-side handshake and sending it would (correctly) be rejected as invalid by the server.
Instead Fiddler can do the client auth. If you want to route HTTPS traffic using client auth through Fiddler, you need to instead configure Fiddler to do the client auth on the session with the server; for a fixed setting you can just drop the identifying certificate in Fiddler's config directory, for per-session settings you need to write some FiddlerScript. The private key (and chain) needs to be in the Windows cert store, not (just) in a file. See:
http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/RespondWithClientCert
https://www.fiddlerbook.com/fiddler/help/httpsclientcerts.asp
Fiddler: Respond to Requests Requiring a Client Certificate (on SO)
https://security.stackexchange.com/questions/72916/can-fiddler-decrypt-https-traffic-when-using-elliptic-curves-client-cert-authe
If your actual problem is getting the client to support client auth when NOT using Fiddler, you need to take Fiddler out of the situation and use other debugging tools like a network trace.
Setup a front thank to VueJS with a basic contact form. Backend is a feathers (node/express) API with a POST route to a mail service (nodemailer) that handle to send the email to the account.
On my machine (localhost) everything is working.
Put on my own server (Ubuntu 17.04) over HTTP (served by Nginx) it's working.
I added let's encrypt SSL certificate.
Now the client received a 200 response when I send an email. I have no error on the server (connection check with transporter.verify()). But I don't get email anymore.
What do I have to configure with a HTTPS connexion ?
I am adding support for HTTP CONNECT request to a client and I can't seem to handle the tunnel properly.
I am able to send a CONNECT request to the proxy which response with a status code of 200. This RFC tell me that the tunnel has been formed with the end server.
How do I use this tunnel from a socket perspective?
On the client side, the socket I opened receives the 200 response from proxy initially. After checking the response should I just send more data into that socket?
I tried this approach and the client just hangs. The data doesn't seem to reach the final server. How to use this socket to do normal HTTP(S) after the tunnel is created?
After checking the response should I just send more data into that socket?
Yes. If you are speaking HTTPS you now start a TLS handshake and then send a properly formed HTTP request and read the response, both via TLS.
I tried this approach and the client just hangs. The data doesn't seem to reach the final server.
So either your handshake was wrong or your HTTP was malformed.
I saw many Tunnel to host:443 in Fiddler traffic interception, when I click it I saw below info:
The selected session is a HTTP CONNECT Tunnel. This tunnel enables a client to send raw traffic (e.g. HTTPS-encrypted streams or WebSocket messages) through a HTTP Proxy Server (like Fiddler).
I also searched this -
Fiddler2: Decrypt HTTPS traffic and Tunnel to host:443
But these didn't answer my question, why do we need the HTTP CONNECT Tunnel? Why does a client need to send raw traffic?
See https://textslashplain.com/2015/11/19/understanding-connect-tunnels/
tl;dr: Browsers need to send CONNECT tunnel requests to proxies in order for the proxy to know to what server the traffic should be sent.
The encryption provided by HTTPS prevents the proxy server from seeing the URLs or HOST headers of the requests, and these are how a proxy normally decides where to send the requests. So, for HTTPS traffic, a different approach is needed-- that approach is that the client tells the proxy: "Hey, give me a tunnel to example.com and let me know when it's ready." The proxy does so and tells the client HTTP/200 Connection established. At that point, the proxy becomes a blind byte-shuffler that takes bytes from the client and sends them to the server and returns the bytes the server replied with back to the client.
How can I stop Fiddler displaying the "407" and "Tunnel To" which look to be generated twice before each successful "200"
GET http://i.stack.imgur.com/G1dzB.png 407 Proxy Authentication Required
( Access is denied. ) (text/html)
GET http://i.stack.imgur.com/G1dzB.png 407 Proxy Authentication Required
( Access is denied. ) (text/html)
GET http://i.stack.imgur.com/G1dzB.png 200 OK (image/png)
and
CONNECT http://www.gravatar.com:443 407 Proxy Authentication Required
( Access is denied. ) (text/html)
CONNECT http://www.gravatar.com:443 407 Proxy Authentication Required
( Access is denied. ) (text/html)
CONNECT http://www.gravatar.com:443 200 Connection established ()
I've enabled the Rule / Hide CONNECTs and the Filter / Show Only Intranet Hosts, but I still get these sessions
[Update]
Tried the customize rules, OnBeforeRequest and added ...
if (oSession.HTTPMethodIs("CONNECT")) {
// works, the sessions are green
// oSession["ui-color"] = "green";
// doesn't work, the sessions appear in grey!
// oSession["ui-hide"] = "true";
}
Steve-- If you want to get a precise answer, save some traffic using File > Save > Session Archive Zip and share the SAZ file (or send using Help > Send Feedback) and I'll have a look.
HTTP/407s are shown because your client is behind an authenticating proxy server; each new connection results in an exchange of credentials to the proxy before the request is sent to the remote web server.
CONNECT requests are shown because when your client sends HTTPS requests, it first sends a CONNECT to Fiddler to tell it where to connect (because your client doesn't expect a proxy like Fiddler to be able to decrypt the secure traffic).
Using the Filters or ui-hide flag should work just fine; it's possible that it's not hiding for a few different reasons, including HTTP Errors or if Fiddler itself generated the requests (which might happen if you enabled Rules > Automatically Authenticate, for instance).
A SAZ file will show me exactly what's going on.