When I use intercept requests in Fiddler, I can inspect CONNECT tunnels. But when I try to issue request from Fiddler's composer, there is no CONNECT session. Is it possible to inspect CONNECTs when issuing requests from Composer?
CONNECT is a special protocol command that is only used in combination with a http proxy. If a proxy receives a CONNECT command from the client this means "please establish a connection to the endpoint included in the CONNECT command".
If you use Fiddler composer the request is sent directly to the server without using Fiddler as a proxy. Thus you won't see a CONNECT command. If you want to see a CONNECT request then you have to use an external tool that uses Fiddler as https proxy.
Related
I have a WSS server running, and I want to intercept WebSocket messages between the client and the server.
I am able to intercept WebSocket messages using WS (no SSL) but haven't had any success with WSS (with SSL). I am getting an error about self-signed certs, which my testing client (wscat) doesn't want to use. (self signed certificate in certificate chain)
And lastly, how would I be able to intercept a connection from a different desktop application? So say if application A is trying to connect to a WSS server, how would I intercept that without telling the desktop application to use a proxy?
Thank you!
Unrelated to the question above, but I am also not able to proxy HTTPS requests because of this error:
sslv3 alert bad certificate
I am getting an error about self-signed certs, which my testing client (wscat) doesn't want to use.
This question is really is about wscat and not mitmproxy. https://stackoverflow.com/a/58149466/934719 mentions that you can pass -n to wscat to disable certificate checks for local testing.
And lastly, how would I be able to intercept a connection from a different desktop application? So say if application A is trying to connect to a WSS server, how would I intercept that without telling the desktop application to use a proxy?
If you cannot tell the desktop application to use a proxy, then it's probably the easiest to set up as a reverse proxy.
I have created a HelloWorld SpringBoot app and deployed it on a EC2 instance. I can invoke it through my HTTP browser with http://<My EC2 instance IPv4 address>/tax after I add the following inbound rules
CustomTCP TCP 8080 <my laptop Ip>
SSH TCP 22 <my laptop Ip>
I went ahead to create a API Gateway with GET method with Integration Type as HTTP and with the above URL. But when I test the GET method, I get
"message": "Network error communicating with endpoint".
I tried giving various inbound rules but no success. Finally after creating a open inbound rule of All Traffic for everyone the API worked fine.
Clearly I cannot go ahead with this open inbound rule, what specific inbound rule should I create for my API to work? What IP should I use in the inbound rule? Does API even have an IP?
From what I understand, your application needs to be publicly accessible to be used by API Gateway.
However, you can use SSL certificates to restrict access to your HTTP backend only to API Gateway. This documentation shows how to do that.
See this for a related discussion on AWS forum.
I have configured JBoss with HTTPS connector only. Now I have problem, that in case I'm using HTTP request to HTTPS connector, it returns page with one ASCII character, instead of some error page, for example 505 or something else what can user inform, about invalid request.
There is no used Apache nor any other web server, where some rules for URL rewriting could apply. Also often used change in web.xml with <transport-guarantee>CONFIDENTIAL</transport-guarantee> tag do not solve this problem, as there must be HTTP request, which is then redirected to HTTPS based on "redirectPort" param in connector configuration and in this case there is not plan to use any other port and it is not possible to combine HTTP and HTTPS listener together on one port.
Is there some way how to configure SSL listener, that way, that it refuse HTTP request, or automatically change to HTTPS?
JBoss 5.1.0
Your browser uses HTTP to talk to server, but on the server side is the security layer (around the HTTP) and it wants to do a SSL/TLS handshake. So the communication fails because client doesn't know about the security on the other side.
The client (browser) receives error message (binary data) from server. The client doesn't know what to do with them, so it presents them to a user as a web page content.
RFC-5246 states:
Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection.
Undertow - a new web server in WildFly - is able to do HTTP Upgrade. But I'm not sure if the upgrade to SSL/TLS is already supported. Nevertheless, the problem with this scenario could be on the browser side.
I wish to setup an HTTPS proxy and have HTTP clients send requests securely to the proxy. For example, a browser can initiate a HTTP GET request which should be an encrypted request to the proxy and the proxy then removes the encryption and then passes the request to the end-site. Squid proxy can be set up to work like this (info here).
I have set up such a HTTPS enabled proxy. But I am unable to write my own HTTP clients to work with it. The same link above mentions that chrome is the only browser that supports such a proxy. I tested Chrome and it was able to work with such an HTTPS proxy.
I wish to gain an understanding of how such a proxy works so that I can write my own HTTP clients.
As I understand it, it's a connection to regular HTTP proxy BUT this connection is made over TLS. The client indeed needs to support this scheme explicitly and existing clients as-is can't be tuned up (without extra coding).
I have a problem with my app that I want to use as sink for the push POST requests. I programmed it in Java as a straight forward servlet, I verified that I can send POST requests to it, but the test push from my consumer’s admin page says 404.
Is it possible that I can’t run the push sink on another port than 80? My secure Tomcat port is 8888. I don’t see any calls from the Foursquare servers in my Tomcat access log.
Thanks!
As stated in Realtime API self signed certificate 4sq seems currently not to be able to send POST requests to other ports than 443 (standard SSL).
I worked around this by using the mod_jk connector to let Apache2 send requests to a special directory directly to Tomcat7. This works for me.