i have a windows 10 computer and a program, that sends to a server (xxx.com aka x.x.x.x) a request. server responses with, for example, "false". that program reads that response and based on that gives output. I need to locally (not on the server, only for me) change that value for, for example, "true". I tried Charles, but it doesn't work for my soft (in browser same requests that go through Charles give "true"). What is the problem here?
Charles "doesn't work" for your program because the HTTP request sent from your program is not intercepted. Charles can autoconfigure the proxy setting for browsers, that's why in your browser "same requests that go through Charles give true".
In order to make Charles intercept your program's HTTP request, a reverse proxy need to be configured:
Step 1. Launch Charles, and go to Proxy - Reverse Proxies...
Step 2. Check Enable Reverse Proxies and click Add.
Step 3. Configure a reverse proxy:
Local port: 59110 // any unused local port
Remote host: xxx.com // the target server
Remote port: 80 // the port opened in target server
Step 4. In your program, send all HTTP requests to localhost:59110.
In this way, Charles can intercept all HTTP requests sent from your program, and you can change the HTTP response data.
If the target server provides HTTPS service instead of HTTP, some additional work need to be done:
SSL-Step 1. In Charles, go to Proxy - SSL Proxying Settings - SSL Proxying
SSL-Step 2. Check Enable SSL Proxying and click Add:
SSL-Step 3. Configure an SSL proxy:
Host: xxx.com // the target server
Port: 443 // the SSL port opened in target server
SSL-Step 4 (1). go to Help - SSL Proxying - Install Charles Root Certificate. This will allow your program trust the self-generated certificate from Charles.
or
SSL-Step (2). If you don't want to install Charles' root CA, you can change your program to prevent certificate error. For example, in Node.js, the following code can prevent program from rejecting unauthorized certificate:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
Related
I am trying to do load testing with JMeter for a spring boot application running locally on port 8080.
Request configured is a GET request, and protocol is https. I get following error message:
javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
at java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:439)
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:184)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
Any input on it would help?
Your are most probably using https to hit the server while you should use http as port 8080 is usually for http.
Otherwise change port to 8443 for https
Did you cross-check the port number on JMeter?
make sure that the same port is defined in JMeter as well.
https://localhost/application/sub/url
For the above URL, the port number is 443 which is the default port for https
https://localhost:8080/application/sub/url
Whereas the above URL uses 8080 for communication.
Please make sure the correct port has been specified.
Additionally, also note that that JMeter itself doesn't allow unsigned certificates. Make sure the certificates are properly signed via Certificating Authority.
I'm reading the spec and trying to understand exactly when 421 might be returned. An example is given but I don't completely understand it.
Background
The spec establishes two conditions that allow for connection reuse:
For TCP connections without TLS, this depends on the host having resolved to the same IP address.
and
For https resources, connection reuse additionally depends on having a
certificate that is valid for the host in the URI.
If the certificate used in the connection has multiple subjectAltName or any of the subjectAltName is a wildcard, then the connection can be reused for any request that has a hostname that is in the list of subjectAltNames or matches any of the wildcards.
Specific Example In the spec
In some deployments, reusing a connection for multiple origins can
result in requests being directed to the wrong origin server. For
example, TLS termination might be performed by a middlebox that uses
the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an
origin server. This means that it is possible for clients to send
confidential information to servers that might not be the intended
target for the request, even though the server is otherwise
authoritative.
Please explain where my understanding of this example is wrong:
An https connection is established to a middlebox with a request that has domain x.com. The middlebox has IP address 1.2.3.4 and x.com resolves to that address. Using SNI, the TLS handshake has x.com and the middlebox returns a certificate valid for that domain. All messages on this connection go from the client to the middlebox or from middlebox to client. Applicaiton level messages from client to middlebox are forwarded by middlebox to an origin on a different connection. Messages from origin to middlebox are forwarded to the client. If the connection is to be reused, meeting the two conditions discussed above is not enough. Specifically, for a request with domain y.com: if y.com resolves to 1.2.3.4 and the middlebox has a certificate valid for y.com, there can still be a problem. Because the original connection did its TLS handshake using x.com and because handshakes are only done at the beginning of new connections, there is no way establishing an https connection that would get the certificate for y.com. So the client incorrectly sends a request on the same connection to y.com. The middlebox rejects the request because the certificate associated with the connection is valid for x.com - not y.com. (The x.com certificate is only valid for x.com and the y.com certificate is only valid for y.com).
None of your examples will trigger a 421 as far as I can see.
Yes you are correct that a connection needs both the IP address and the SAN field in the certificate to be valid - without those a connection should not be reused.
So what would trigger a 421? As far as I can tell it will be mostly due to different SSL/TLS setups.
For example:
Assume website A (siteA.example.com) and website B (www.example.com) are both on same IP address. Assume website A has a wildcard cert for *.example.com and website B has a specific one. Could be a few reasons for this: for example it serves an EV cert for the main website which can't be a wildcard cert.
So cert A covers website A and website B. As does the IP address. So if you are connected to website siteA.example.com, and then try to connect to www.example.com then technically, by HTTP/2 standards, you could reuse the connection. But we wouldn't want that to happen, as we want to use our EV cert. So the server should reject with a 421. Now in this example the webserver is able to distinguish the correct host and has a valid cert for that host so could, in theory, serve the correct content under the wildcard cert, instead of sending a 421 - but since that wildcard cert is not defined for that virtualhost it should not do this.
Other examples include if you have different ciphers set up on different hosts. For example site A has super lax HTTPS config, because it's not really secure content and they want to reach even legacy browsers, but site B has super secure config and only accepts the latest TLS version and strong ciphers. Here you obviously wouldn't want them to reuse the same connection details. See here for a real would example of this.
Also this is only an issue for certain browsers, depending on how they decide to connection share. This page shows how different each of them do this (at least at the time of this blog post not not aware of anything changing since then): https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
Also note that some bugs will exist with this (for example: https://bugs.chromium.org/p/chromium/issues/detail?id=546991). Best advice is: if you do not want connection sharing to happen, have a different IP address and/or ensure no overlaps in certificates.
I had follow all the below given Steps.
Please check and suggest me solution for this.
1.Create Thread Group.
2.HTTP Request(with Port 8080 and IP/Server Name as localhost.
3.HTTP Request Defaults(with Port 8080 and IP/Server Name as localhost).
4.Added Recording Controller.
5.Under Workbench created HTTP(s) Test Script Recorder
6.Updated URL patterns (.*.html).
7.Added View Result Tree.
8.Clicked on Start and install Root CA certificate(Click OK).
9.Set a Proxy in Firefox.
10.Firefox Option Advanced Network Setting.
Check the Manual Proxy Configuration.
HTTP Proxy: localhost and Port: 8080.
11.Check the "Use this Proxy Server for all Protocol".
No Proxy for "localhost".
Finally I have did not see any script that has been recorded.
You Can Follow these below steps:
Open Jmeter.
Click on Templates... (File->Templates... )
Just Click on "Create" button.
Then open up your Firefox browser.
Then Open Menu-> Options -> Advanced -> Network -> Connection Settings.
Then configure just like this.
Then just click OK.
Start the HTTP(s) Test Script Recorder from Jmeter.
9.Now Install Root CA certificate.
Restart your Firefox and you are just ready to record your test script.
You will find your recorded script under the "Recording Controller" section!!
Hope, this will help you. :)
It might be the case you're trying to record secure (HTTPS) traffic.
Make sure "Use this proxy server for all protocols" box is checked
Make sure "No Proxy for" box is empty
You can also consider an alternative recording approach - JMeter Chrome Extension - in that case you won't have to worry about proxies, SSL certificates, browser configuration, etc. - click one single button and you're all set.
- In step #2, You don't need to specify anything in HTTP Requests, HTTP requests will
be added automatically when you record your script successfully.
- In step #3, DO NOT use server name as "Localhost" and port number as JMeter's port.
Only when you want to test HTTPS domains, you specify HTTPS as a protocol.
Also, if you are testing an application that requires a specific port number (Example:
htts://somedomain.com:9595/somepath/) you specify the Server/IP Name and the PORT in the
HTTPS Default.
- In step #5, you specify JMeter port number (8080 or 8888 or...), and chose "Target
Controller" to "Use Recording Controller". You will find recorded script in Recording
Controller when you expand it after recording is done.
- In step #10, use the same port number you specified in step #5.
For me, the solution was to create an alias for 127.0.0.1 in /etc/hosts:
127.0.0.1 myserver
and create the JMeter script from the Recording template as detailed at https://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.html, specifying "myserver" as the host (instead of www.example.com).
Also, if your backend listens on a specific port, you have to specify that port in the "HTTP Request Defaults", under "Port Number".
I'm trying to use Fiddler to capture traffic that comes to my machine on its external ip address, and redirect it to the loopback interface without affecting the host header.
I have added the following to the OnBeforeRequest method:
if (oSession.HostnameIs("MyMachineName")){
oSession.bypassGateway = true;
oSession["x-overrideHost"] = "localhost";
}
This works fine for http traffic: I do indeed see a request to http://MyMachineName hit the loopback adaptor with its host header intact.
However, when intercepting https traffic I get the following in the response raw view:
fiddler.network.https> HTTPS handshake to auth.time-wise.net failed. System.IO.IOException The handshake failed due to an unexpected packet format.
I have Fiddler configured to capture and decrypt https traffic.
Does anyone know why this problem occurs and how it can be remedied?
Edit: in response to Eric's request for more information
Fiddler is running as a proxy (i.e. as standard), listening on port 8888.
The clients are (currently) web browsers on the same machine, and so are automatically using the Fiddler proxy, as they've picked up the change in default proxy.
You've left out some important details (e.g. what port is Fiddler running on, and how did you configure the remote client to send its traffic to Fiddler?)
Having said that, you will probably want to change your use of x-overrideHost to x-overrideHostname such that the port number of the traffic being retargeted is preserved.
I enabled "Decrypt HTTPS traffic" and "Ignore server certificate errors" in Fiddler but the traffic of one website is not being showed.
This is the error that Fiddler is returning:
[Fiddler] The connection to '...' failed. System.Security.SecurityException Failed to negotiate HTTPS
connection with server.fiddler.network.https> HTTPS handshake to
... failed. System.IO.IOException Received an unexpected EOF
or 0 bytes from the transport stream.
I remember that I could ignore this error in Fiddler script, but I really don't remember.
Does anyone know what's going on?
Thanks! =)
What is the site's URL?
It is probably caused by either of these two issues: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx or http://blogs.msdn.com/b/fiddler/archive/2012/03/29/https-request-hangs-.net-application-connection-on-tls-server-name-indicator-warning.aspx
The old workaround is to configure Fiddler to only use SSL3 when talking to the host in question. The newer workaround is to either use Fiddler4 with the latest .NET4.5.2 framework, or if you're using Fiddler 2.5.1, see the "SNI Hack" section of http://www.telerik.com/blogs/what-s-new-in-fiddler-4-5-1
In your OnBeforeRequest event handler, add the following code to fix the issue for certain sites:
if (oSession.HTTPMethodIs("CONNECT") && oSession.HostnameIs("BuggySite.com"))
{
oSession["https-DropSNIAlerts"] = "yup";
FiddlerApplication.Log.LogString("Legacy compat applied for request to BuggySite.com");
}
A bit late for the poster unfortunately but I just needed to add tls1.2:
Tools
Options
HTTPS
Protocols
Add tls1.2 to the end of the list and click ok
I was seeing the following exception:
System.Security.SecurityException Failed to negotiate HTTPS connection
with server.fiddler.network.https. HTTPS handshake to
api.etadirect.com (for #9) failed. System.IO.IOException Unable to
read data from the transport connection: An existing connection was
forcibly closed by the remote host. An existing connection was
forcibly closed by the remote host
I was able to fix it by enabling the TLS1.2 protocol which is not enabled by default for outgoing connections
Tools -> Options -> HTTPS -> click on protocols list