I have to connect to a REST webservice, and use a certificate to authenticate myself.
Everything works perfectly when I connect from OUTSIDE our corporate network and DONT use a proxy server.
The problem is that i have to consume the service from WITHIN our network, where i HAVE to use the proxy server.
When i try from within the network i just get a "401 - Unauthorized"
private static void RestWithCert(string certificatePath,string baseUrl,string method)
{
HttpClientHandler handler = new HttpClientHandler();
//when trying the code OUTside our company network I remove the proxy below
handler.Proxy = new WebProxy("http://proxy.company.dk");
handler.ClientCertificates.Add(new X509Certificate2(certificatePath, "password"));
HttpClient client = new HttpClient(handler);
client.BaseAddress = new Uri(baseUrl);
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
HttpResponseMessage response = client.GetAsync(method).Result;
var status = response.StatusCode;
}
Outside the network, without proxy: Status = OK
Inside the network, with proxy: Status = Unauthorized
Inside the network, without proxy: Connection timed out
I have NO control over either Proxy or the webservice i am trying to access
What is happening? Is the proxy intercepting the certificate, and replacing it?
A proxy can capture SSL traffic and connect to the target server by acting as a ManInTheMiddle or allow the SSL connection to be made directly to the target server.
When client certificates are required, the proxy must allow the direct connection, because the proxy can not present a valid certificate when it is needed by target server. During SSL handshake some interchanged data is signed with the private key of the client certificate to authenticate the message and the proxy does not have that private ke
Probably your proxy is capturing the traffic. I suggest checking this. You can verify if the certificate received during SSL connection corresponds to the target server or proxy
Related
I am attempting to create a windows service that opens a secure web socket and listens for connections on a certain port (wss://localhost:1234). The sample code includes referencing a certificate for the server to use:
var serverCertificate = new X509Certificate2(certificatePath, "mypassword");
This works fine.
The issue happens when the a client attempts to connected:
using (SslStream n = new SslStream(client.TcpClientInstance.GetStream()))
{
n.AuthenticateAsServer(serverCertificate, clientCertificateRequired: false, enabledSslProtocols: System.Security.Authentication.SslProtocols.Tls12, checkCertificateRevocation: false);
This line errors out with a generic "A call to SSPI failed, see inner exception", "InnerException = {"An unknown error occurred while processing the certificate"}":
This occurs with a self-signed cert registered in the Trusted Root Certificate Authorities.
Interestingly enough if I use the generic localhost cert generated by Visual Studio it works.
Any thoughts welcome.
TIA
Might solve your issue.
Create a sub-domain like sub-domain.domain.com ( using your actual domain )
With an A record to 127.0.0.1
Request a SSL certificate for sub-domain.domain.com
When you open a connection to sub-domain.domain.com it will be valid and should resolve to 127.0.0.1 which is where your "server" is listening.
I am currently using the activemq-cpp c++ client to connect to the backend server. When using the TCP protocol, it is possible to communicate. I am using the example above at https://activemq.apache.org/components/cms/example. But now I need to use the SSL protocol. My code is as follows:
brokerURI ="failover:(ssl://xxxx:61617)";
auto connectionFactory = new ActiveMQConnectionFactory(brokerURI);
connectionFactory->setUsername(username);
connectionFactory->setPassword(password);
connection = connectionFactory->createConnection();
connection->start();
I got stuck in the start function and didn't throw any exceptions. I don't know why. Could give me a simple c++ ssl code connection demo for me to learn? Thank you.
The [example][1] documents the SSL configuration that you need to do, which is to tell the library where the key store, and trust store (and password) live.
// SSL:
// =========================
// To use SSL you need to specify the location of the trusted Root CA or the
// certificate for the broker you want to connect to. Using the Root CA allows
// you to use failover with multiple servers all using certificates signed by
// the trusted root. If using client authentication you also need to specify
// the location of the client Certificate.
//
// System::setProperty( "decaf.net.ssl.keyStore", "<path>/client.pem" );
// System::setProperty( "decaf.net.ssl.keyStorePassword", "password" );
// System::setProperty( "decaf.net.ssl.trustStore", "<path>/rootCA.pem" );
//
// The you just specify the ssl transport in the URI, for example:
//
// ssl://localhost:61617
//
I have a remote server which may or may not be running using a valid SSL cert (using self-signed SSL cert).
We are making connection to remote server, which may fail if remote server is using self-signed SSL cert. So, we want to be able to download/view the remote server cert if our SSL handshake fails.
If I use Apache HTTP Client then I couldn't find a method which could allow me to view remote server certificate (you can do it with HttpsURLConnection but we are trying to avoid using it see this example).
I also looked into Spring RestTemplate, and it didn't provide any option either - I searched on Google and didn't find anything around Spring or Apache HTTP Client.
This should give you pretty much a complete control over the process of trust verification.
SSLContext sslContext = SSLContextBuilder.create()
.loadTrustMaterial((chain, authType) -> {
for (X509Certificate cert: chain) {
System.out.println(cert.getSubjectDN());
}
// Let the standard trust managers decide
// whether or not the cert chain is trusted
return false;
})
.build();
CloseableHttpClient client = HttpClientBuilder.create()
.setSSLContext(sslContext)
.build();
I have built an application called Tun2Socks GUI. It's program to make Socks proxy o be transparent.
Usually it use SSH port forward or TOR as SOCKS service, but I want it can use HTTP proxy too. So I build SOCKS5 proxy my self that connect to that HTTP proxy. It's working good with capturing HTTP request from client to be sent to HTTP Proxy.
The problem when the client send SSL request, I cannot capture the request to be forwarded. How the best method to make SSL request from SOCKS proxy through HTTP Proxy?
Schema of request transportation like here :
Client SSL request > SOCKS Proxy > HTTP Proxy > Internet
Thanks
When a client intentionally wants to establish an SSL session with a target server through a proxy, it does not establish an SSL session with the proxy itself. The client first tells the proxy to establish a connection to the target server, and THEN the client initiates an SSL session with the target server. In that situation, it is not possible for the proxy to sniff the traffic as it is encrypted, nor should it be trying to. A proxy is just a pass-through, it exchanges raw data back and forth between client and server as needed. The proxy should not care what kind of requests the client is sending, since the client tells the proxy where to connect.
If you have injected your proxy in between the client and server in such a way that the client has no knowledge that your proxy exists, the client will not know that it needs to adjust its requests to make them proxy-friendly. The client will be connected to your proxy but it will think it is connected to the target server, and thus will initiate an SSL handshake that your proxy will have to respond to. Only then will your proxy have access to the client's request data (provided the handshake is successful, such as if the client does not verify peer certificates), and can then tunnel the unencrypted data to the next proxy as needed.
Update: I just thought of another scenario that should work for both cleartext and SSL connections. Regardless of whether you are transparently redirecting the client's outbound connection to your SOCKS proxy without the client knowing about it, or the client intentionally connects to the SOCKS proxy and tells it where to go, the SOCKS proxy knows the client's target host/IP:port. The SOCKS proxy can either connect directly to the target, or it can connect to the HTTP proxy and ask it to create a tunnel to the target via the HTTP CONNECT method. If successful, the client has a viable connection to the target, and any data the client sends, SSL or otherwise, will flow as-is to the target, and vice versa. Neither the SOCKS proxy nor the HTTP proxy needs to know anything about the client's request other than the target host/IP:port. That is in the initial SOCKS request, either captured from the intercepted TCP header, or explicit from the client.
I just read over node-tls-proxy (http://code.google.com/p/node-tls-proxy/), a https proxy. I like the idea of it, but I'm not getting why this proxy needs a local http server (see the local-proxy.js script).
So I was wondering if this is necessary?
My idea of the proxy was actually like this: Client -> HTTPS Connection to trusted Server/Proxy -> Internets
In this case network sniffing between the Client and the Server wouldn't (hardly) be possible because it would be ssl encrypted.
Thanks,
Seb
If I get the idea correctly, the goal is to set up a "remote" proxy in a location that one trusts to be secure. Your client shall only communicate with this remote proxy using TLS, the remote proxy is then allowed to do the actual (no longer encrypted) HTTP requests.
What you do on the client side now is this: you configure the "local" proxy in your browser. Since you type "http://..." in your browser even when using the proxy, your browser will initiate an unencrypted HTTP connection to the local proxy first. Then the local proxy will open an encrypted TLS connection to the remote proxy and forward your request over a secured channel.
This means you need the local proxy for the purpose of "transforming" HTTP into HTTPS requests because your browser will dutifully only use HTTP when asked to make an actual HTTP request.