I wonder is there any possibility that cURL to accept a connection request from the server and verify certificates, requested ports by listening on some port?. If in a case of success, receives data from the server until the server closes the connection.
Backgound : C++11
Thanks
Uma
Related
I am trying to implement a Socks5 server that could relay both HTTP and HTTPS traffic.
As the RFC1928 mentions, the following steps to establish a connection and forward the data must be taken :
Client sends a greeting message to the proxy.
Client & proxy authentication (assuming it is successful).
Client sends a request to the proxy to connect to the destination.
The proxy connects to the destination and sends back a response to the client to indicate a successful open tunnel.
The proxy reads the data from the client and forwards it to the destination.
The proxy reads the data from the destination and forwards it to the client.
So far, the proxy works as it should. It is able to relay HTTP traffic using its basic data forwarding mechanism. However, any request from the client to an HTTPS website will be aborted because of SSL/TLS encryption.
Is there another sequence/steps that should be followed to be able to handle SSL/TLS (HTTPS) traffic?
The sequence you have described is correct, even for HTTPS. When the client wants to send a request to an HTTPS server through a proxy, it will request the proxy to connect to the target server's HTTPS port, and then once the tunnel is established, the client will negotiate a TLS handshake with the target server, then send an (encrypted) HTTP request and receive an (encrypted) HTTP response. The tunnel is just a passthrough of raw bytes, the proxy has no concept of any encryption between the client and server. It doesn't care what the bytes represent, its job is just to pass them along as-is.
What is the procedure to change ws into wss?
Whether wss is make upgrade over normal HTTP or wss works only HTTPS?
webSocket = new WebSocket("ws://localhost:port/Esv/ocp");
works fine, when I changed ws to wss
webSocket = new WebSocket("wss://localhost:port/Esv/ocp");
it shows this error:
Error in connection establishment: net::ERR_SSL_PROTOCOL_ERROR
Short version
To SSL or not SSL
You may have a SSL certificate issue. The connection point rule can be summarized as:
wss connects on https only
ws connects on http
and vice-versa:
https accepts wss only
http accepts ws only
Errors
Following situations will lead you to an error (tests done under Firefox):
If you want to connect a wss connection to a http endpoint. In my tests, I had an
InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable
If you want to connect a ws connection to a https endpoint, you'll have the error
SecurityError: The operation is insecure.
Formal answer
The bible of websocket is RFC 6455. In section 4.1.5:
If /secure/ is true, the client MUST perform a TLS handshake over the connection after opening the connection and before sending the handshake data [RFC2818]. If this fails (e.g., the server's certificate could not be verified), then the client MUST Fail the WebSocket Connection and abort the connection. Otherwise, all further communication on this channel MUST run through the encrypted tunnel [RFC5246].
The secure flag is defined by the URI. Section 3 defines what is secure
The URI is called "secure" (and it is said that "the secure flag is set") if the scheme component matches "wss" case-insensitively.
TL;DR
If you want to use wss:
you must have SSL activated
your endpoint point must be secured (https://...): "security downgrade" is not allowed
If you want to use ws:
Make sure your endpoint does not have SSL enabled (http://...)
I'm using fiddler to debug android app, I can capture the HTTP request and Http response, but I can not capture the HTTPS request/response , I already install the fiddler root certificate.
The request is :
# Result Protocol Host URL Body Caching Content-Type Process Comments Custom
119 200 HTTP Tunnel to api.find.nutspace.com:443 0
In the request inspector , I got that:
After the client received notice of the established CONNECT, it failed to send any data.
I got no response body data , the headers of the response is :
HTTP/1.1 200 Connection Established
FiddlerGateway: Direct
StartTime: 11:49:35.178
Connection: close
Can anyone know why it failed to send any data?
When this problem occurs, the typical explanation is that you failed to properly configure Android to trust Fiddler's root certificate. As a consequence, after the Connection is established, the Android application examines the certificate, notes that it is not trusted, and decides not to use the connection to send a secure request.
You haven't specified what application you're using, how you attempted to trust the certificate, and whether you can capture HTTPS traffic in the Android browser.
I'm building a WebClient library. Now I'm implementing a proxy feature, so I am making some research and I saw some code using the CONNECT method to request a URL.
But checking it within my web browser, it doesn't use the CONNECT method but calls the GET method instead.
So I'm confused. When I should use both methods?
TL;DR a web client uses CONNECT only when it knows it talks to a proxy and the final URI begins with https://.
When a browser says:
CONNECT www.google.com:443 HTTP/1.1
it means:
Hi proxy, please open a raw TCP connection to google; any following
bytes I write, you just repeat over that connection without any
interpretation. Oh, and one more thing. Do that only if you talk to
Google directly, but if you use another proxy yourself, instead you
just tell them the same CONNECT.
Note how this says nothing about TLS (https). In fact CONNECT is orthogonal to TLS; you can have only one, you can have other, or you can have both of them.
That being said, the intent of CONNECT is to allow end-to-end encrypted TLS session, so the data is unreadable to a proxy (or a whole proxy chain). It works even if a proxy doesn't understand TLS at all, because CONNECT can be issued inside plain HTTP and requires from the proxy nothing more than copying raw bytes around.
But the connection to the first proxy can be TLS (https) although it means a double encryption of traffic between you and the first proxy.
Obviously, it makes no sense to CONNECT when talking directly to the final server. You just start talking TLS and then issue HTTP GET. The end servers normally disable CONNECT altogether.
To a proxy, CONNECT support adds security risks. Any data can be passed through CONNECT, even ssh hacking attempt to a server on 192.168.1.*, even SMTP sending spam. Outside world sees these attacks as regular TCP connections initiated by a proxy. They don't care what is the reason, they cannot check whether HTTP CONNECT is to blame. Hence it's up to proxies to secure themselves against misuse.
A CONNECT request urges your proxy to establish an HTTP tunnel to the remote end-point.
Usually is it used for SSL connections, though it can be used with HTTP as well (used for the purposes of proxy-chaining and tunneling)
CONNECT www.google.com:443
The above line opens a connection from your proxy to www.google.com on port 443.
After this, content that is sent by the client is forwarded by the proxy to www.google.com:443.
If a user tries to retrieve a page http://www.google.com, the proxy can send the exact same request and retrieve response for him, on his behalf.
With SSL(HTTPS), only the two remote end-points understand the requests, and the proxy cannot decipher them. Hence, all it does is open that tunnel using CONNECT, and lets the two end-points (webserver and client) talk to each other directly.
Proxy Chaining:
If you are chaining 2 proxy servers, this is the sequence of requests to be issued.
GET1 is the original GET request (HTTP URL)
CONNECT1 is the original CONNECT request (SSL/HTTPS URL or Another Proxy)
User Request ==CONNECT1==> (Your_Primary_Proxy ==CONNECT==> AnotherProxy-1 ... ==CONNECT==> AnotherProxy-n) ==GET1(IF is http)/CONNECT1(IF is https)==> Destination_URL
As a rule of thumb GET is used for plain HTTP and CONNECT for HTTPS
There are more details though so you probably want to read the relevant RFC-s
http://www.ietf.org/rfc/rfc2068.txt
http://www.ietf.org/rfc/rfc2817.txt
The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.
My websocket server listens on port 8080 with no proxy.
Most of the time I'm getting requests with the Upgrade Websocket header and it works fine.
Sometimes I'm getting HTTP CONNECT requests.
Is this a valid request?
Does it means that there is a proxy server between the client and the server?
How my server is suppose to respond to the CONNECT request?
Thanks
You are getting CONNECT requests because you are likely to have configured your browser to use a proxy. If you directed your browser to use port 8080 on your local IP address, it will assume there is a proxy and that means when you ask for a secure connection, the browser leads with CONNECT.
You will need to add support for SSL/TLS tunnelling to your server to deal with this.