Our integration partner was using our Web service with http: 8090 and now we are moving to https: 8443 so they tried to update the WS URL but they are getting "handshake error". They are asking whether they can still use http 8090. If we route any traffic coming from http 8090 to https 8443 in the webserver config, will they still get handshake error?
When you create a redirect, the server sends a HTTP 302 which the client is obligated to follow, which means that they should still get the error. depending on your setup, and config, they may be able to send the request anyway, but if that works, then all your traffic is potentially insecure...
Related
I have a Django app which returns a large JSON while calling an API.
The problem is when I'm requesting the data, the data itself is truncated which is crashing the frontend.
I'm using cloud front for DNS and SSL and other feature provided by them for caching and improved performance.
I tried curling the API and got the following error from curl:
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err
2)
I tried disabling the Cloudflare but didn't work. On my localhost, however, everything works fine.
HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
Closing connection 0
TLSv1.2 (OUT), TLS alert, Client hello (1): curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
The JSON should be fetched entirely without getting chunked.
I got the same error with an application behind an AWS Application Load Balancer, using command:
curl "https://console.aws.example/api/xxx" -b "SESSION=$SESSION"
15:14:30 curl: (92) HTTP/2 stream 1 was not closed cleanly:
PROTOCOL_ERROR (err 1)
I had to force the use of HTTP/1.1 with the argument --http1.1
So the final command is:
curl "https://console.aws.example/api/xxx" -b "SESSION=$SESSION" --http1.1
I had this issue with AWS's Application Load Balancer (ALB). The problem was that I had Apache configured to use http2, but behind an ALB. The ALB supports http2 by default:
Application Load Balancers provide native support for HTTP/2 with HTTPS listeners. You can send up to 128 requests in parallel using one HTTP/2 connection. The load balancer converts these to individual HTTP/1.1 requests and distributes them across the healthy targets in the target group. Because HTTP/2 uses front-end connections more efficiently, you might notice fewer connections between clients and the load balancer. You can’t use the server-push feature of HTTP/2. 1
So, curl was using HTTP/2 to connect with the ALB, which was then converting it into an HTTP/1 request. Apache was adding headers to the response asking the client to Upgrade to HTTP/2, which the ALB just passed back to the client, and curl read it as invalid since it was already using an HTTP/2 connection. I solved the problem by disabling HTTP/2 on my Apache instance. Since it will always be behind an ALB, and the ALB is never going to make use of HTTP/2, then there is no point of having it.
Fix or Remove the Content-Length header in your HTTP request.
I was trying to connect to an AWS Gateway when this issue occurred to me. I was able to get the correct response using POSTMAN but if I copied over the same headers to curl, it would give me this error.
What finally worked for me was removing the Content-Length header as the length of the request in curl wasn't matching the same as it was in POSTMAN.
Since in my case I was only testing the API so this is fine, but I wouldn't suggest removing this header in production. Check to make sure the length is calculated correctly if this is occurring to you in a codebase.
With Nginx, you can experience this error in curl by having two http2 virtual hosts listening on the same server name. Running a check on your nginx config file will throw a warning letting you know that something isn't right. Fixing/removing the duplicate listing fixes this problem.
# nginx -t
nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "example.com" on [::]:443, ignored
Recently i started to write a proxy(web debugging) software.
and handled the GET request well.
sometimes i get CONNECT messages from the client, so i connect to the target server and reply the client by "200 Connection Established".
is that it all??
because after it i don't get any messages
from the server or the client.
so i got confused.
I want to know all the steps of https CONNECT message request and responses until an https site(like https://google.com) gets loaded.
Thank you.
The CONNECT request is used to set up a connection tunnel. This is used mainly to allow access to https sites through an http proxy.
The web proxy is expected to set up a proxy connection to the indicated host, and then proxy the traffic between the two connections, until one or the other terminates.
After establishing the connection, you expect to see either the client or the server start sending something to the other. Your proxy code should be prepared, at any time, to receive more data from either the client or the server, to be forwarded to the other party. If not, your proxy is not doing something correctly. It is not your proxy's job to handle https negotiation. Once the connection is established, your proxy must transparently proxy all the data, and it is the client's and the server's task to talk https with each other.
When I type google.com (note, I didn't specify it's http or https.)in the chrome, the chrome automatically goes to https://google.com, which is a secured socket connection that connect to port 443. So, my question is how does my browser know it should connect to 443 instead of 80? Or, to put it more simply, how does my browser know google.com use secured socket for http?
HTTP procotocol!
Chrome by default appends http:// prefix, and sends the http://google.com request to the HTTP port:
GET / HTTP/1.1
Host: google.com
...
Then google.com replies:
HTTP/1.1 301 Moved Permanently
Location: https://google.com
...
Notice the https in the Location header.
Then Chrome automatically handles redirections, and sends the second request to the HTTPS port.
GET / HTTP/1.1
Host: google.com
...
Which finally replies with the content displayed in the browser:
HTTP/1.1 200 OK
....
The browser usually tries HTTP first, then gets a redirect to HTTPS. That's the common case, but not the only one. Chrome and Firefox support the notion of HTTP Strict Transport Security Preload Lists which are lists of sites which should only be contacted via HTTPS, even if referenced with a HTTP URL.
You can learn more about HSTS here.
its not your browser doing it but google redirecting http://www.google.com to https://www.google.com.
I have a C++ server in linux using Mongoose listening on port 8080 for http requests. I'm using port 8080 because I have an Apache server already using port 80.
The reason I have my C++ server listening for http requests is so that I can receive the http GET sent by Facebook to get a user's Facebook info. For the Facebook server side Auth I'm redirecting to localhost:8080.
I am correctly getting the information sent from Facebook, but now Apache isn't serving up my html to the clients webpage (which works correctly if I only redirect to localhost).
Is it possible to make both of these work? Is the client still trying to get the index.html from port 80 or does it expect 8080 to now send this?
Is 80 equal 8080? Apparently no. So the both ports might be listened by different applications.
Try to inspect income requests with Wireshark (packet analyzer).
I've just started studying Winsocks and I've a simple question for you: how can I determine if the connection to a server must take place over a HTTP or HTTPS connection?
Let's say I want to connect to randomsite.random, how can I know what kind of connection I need? I know that for HTTP I must connect to port 80, while for HTTPS is needed 443, but how can I determine WHEN is needed a HTTPS connection?
Thank you for the attention!
The same way a web browser decides: Based on the URL you are trying to load. In a web browser, the URL begins with http or https, which is used to determine whether an SSL connection should be used. This is also used to determine the port if no port number is specified in the URL.
Many sites offer both a secure and a non-secure version. Some offer only a secure version, but still run a non-secure server which issues a redirect to the URL of the secure version. If you implement following of redirects, you don't need to worry about which version to use: it will happen automatically.
This is usually a function of the site you are connecting to.
If the site requires a HTTPS connection, then if you connect over HTTP you will get a redirect response code with a HTTPS URL.
Firstly, it's not always port 80 and port 443. Secondly, you won't establish successful communication if you use the wrong communication protocol. As said in another answer, if you try to connect via HTTP to an HTTPS server, it will give you a redirect response code with an HTTPS URL.
Most of the time, you have this information before-hand!