We are using Kerberos to authenticate HTTPS request. We wish to reuse the connection for requests to same endpoint by using same curl handle. This works fine for HTTP connections. However, each rest request we sent will send two request, first will get 401 to get back authentication token and then 200 for the data. Then curl will close the connection and reconnect again for following rest request. This is extremely inefficient, is there a way to cut down all the authentication cost? Thanks a lot!
Related
can the proxy server intercept my https request and set cookies before actually sending the request?
I'm going a GET on an url from chrome browser. In the development tools, under "Network", I noticed that the first request, the one that I made, has cookies set. but I did not set any cookies.
any thoughts?
No it can't. To proxy HTTPS requests your browser issues HTTP CONNECT command (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT). Proxy then creates a tunnel between the browser and a target server.
A conventional proxy can neither view nor manipulate a TLS-encrypted data stream, so a CONNECT request simply asks the proxy to open a pipe between the client and server. The proxy here is just a facilitator - it blindly forwards data in both directions without knowing anything about the contents. The negotiation of the TLS connection happens over this pipe, and the subsequent flow of requests and responses are completely opaque to the proxy.
It cannot modify or see what is being transferred as it is protected by TLS encryption.
The only way to modify HTTPS conenctions on the fly is if you install some external CA certificates on your computer. This is known as MITM Attack.
I am currently making a server that serves API requests to mobile clients. I want to somehow block web browsers or tools like cURL from making requests to my API. Is that possible? If it is, what is the most secure and efficient way of doing that?
Your server cannot really block individual curl requests. However, your server can refuse serving requests that it doesn't want to.
To explain it a bit better, suppose your mobile sends in an HTTP request. Any curl request can be made to mimic that exact mobile request, making it look like it came from your mobile (by sending the same headers, auth params etc). Your server doesn't see curl, it just sees the HTTP request.
You might try blocking requests with user agent string that looks like it comes from curl, but this won't be of much use; as I mentioned, curl can be used to mimic any HTTP request.
Coming to your comment
I have an authentication API that gives an auth token once the user logs in, but you could log in using cURL (and even the web browser)
If you have an https server, your requests are safe from getting hijacked, since the user can only read his own requests, not the ones sent by other devices. So you don't really need to block curl requests.
I'm making an HTTP proxy in C++; when a client sends a GET or CONNECT request to the proxy, the proxy parses the HTTP header of the packet, resolve the hostname in it, opens another socket to the server destination and send client's request. Then the proxy will send server's response to the client.
Here's the GET and CONNECT requests from the client sent by the proxy to the server:
GET http://www.gstatic.com/generate_204 HTTP/1.1
CONNECT cr-input.getspeakit.com:443 HTTP/1.1
But when I parse a GET response from server, I find a 400 status code, i.e. Bad Request: this seems to be (from Wikipedia):
a malformed request syntax, invalid request message framing, or deceptive request routing.
Do I send wrong arguments to the server in the GET request?
GET. The syntax is not wrong but if the request has not been faked by you and it is really going to www.gstatic.com you can check yourself that any kind of requests generates a 40x status code. That's a domain used for Google for offloading static content. Whether that's still the case and why it returns 40x for the requests. Go to Google.
CONNECT. If you are forwarding the CONNECT to the server, this is wrong. A CONNECT is meant to open an end to end binary connection bypassing your proxy. The sequence would be:
Get connect request from client
Open TCP connection to IP:Port (after DNS resolution obviously)
Return "200 OK" to the client if the connection was successfully opened or an error code of your choice (plus optionally some explanation in Text/HTML form for the end user)
If data is received from either end -> forward it to the other end until one of the connections is closed, when you close the other end.
I have a browser that's sending requests through a very slow connection to a python web-proxy. The slowness isn't an issue with normal HTTP GET and POST requests, but when I try to open an HTTPS site it's failing. The proxy is getting the CONNECT request from the client and opening the connection with the server, but if the handshake doesn't finish in 30 seconds, the server is ending it.
Is there any way I can modify the proxy to keep the handshake open long enough for the client to finish it? Maybe some sort of SSL handshake keep-alive?
I am trying to setup very simple WSO2 ESB Proxy service. While using it, I am getting HTTP 202 response back and WSO2 ESB is not doing anything with the request beside logging it. Here is the background of my setup
My service implementation is using SOAP 1.2 over Http 1.1. When my client opens the connection to the server, it fires first request and asks for keep-alive connection. The ESB passes the request to the actual implementation and sends response back with transfer-encoding as chunked. So far it works as desired.
After the initial request response exchange, my client submits several requests in parallel and I get HTTP 202 responses for all of them. Looking at logs, it seems ESB is not sending the request to the actual implementation ever.
Is there something that I am doing wrong? How do I fix it?
What happens in this scenario is that your subsequent requests are hitting the main sequence of the WSO2 ESB. That is why you can only see a log for those requests. As you have already narrowed down this happens due to the jsessionId attached to the URL. To overcome this issue you can create a REST API with URL pattern to match the correct URL path. Please refer the following documentation.
https://docs.wso2.com/display/ESB481/Creating+APIs