Sorry in advance for my not-perfect english.
I'm trying to capture the http/https traffic in real-time from a Java program.
Thanks to Jnetpcap library, I managed to do it quite easily but, for the https traffic, I don't manage to get just the headers of the packets, even if I ask to capture all the tcp packets without port filter. I don't understand how sofwares like Fiddler manage to do it, e.g. to have the domain name like facebook.com or google.com.
Is there a way to do it in Java ?
Thanks!
For HTTPS, Fiddler uses its own SSL certificate. So from both the client and server view the connection is secure. Fiddler is a Man-In-the-Middle (Proxy), able to decrypt incoming data from the client and then encrypting it for the server.
Related
Since I am new to this SSL I am asking this question. I googled and got this below mentioned HTTPS server python script. May I please know if its one way SSL or Two way SSL? And also how do I take dump to see the communication between client and server?
My requirement is to have one way SSL.
import BaseHTTPServer, SimpleHTTPServer
import ssl
httpd = BaseHTTPServer.HTTPServer(('localhost', 4443), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='path/to/localhost.pem', server_side=True)
httpd.serve_forever()
May I please know if its one way SSL or Two way SSL
This is one-way, i.e. the server is sending its certificate but not requesting a certificate from the client. The server could request a client certificate by adding cert_reqs=ssl.CERT_REQUIRED to the call of ssl_wrap.
And also how do I take dump to see the communication between client and server?
Use the packet capture tool of your choice and which is supported on your unknown platform. wireshark is a good choice and you will find plenty of documentation about how to use it.
In HTTPS (SSL) browser send the encrypted data which can be Decrypted by server only.
To confirm it, i did set up the burp proxy on my Firefox browser so that it intercepts the request sent to HTTPS server by browser .
When i receive it at burp, i see the data as entered by user though i was expecting browser must have encrypted that but did not.
So at what point of time browser encrypt data over HTTPS ?
Most pieces of software that do this (e.g. Anti-virus scanners) replace the https certificate with their own so the https traffic can be man-in-the-middled by the software.
While I'm not familiar with Burp, it looks like it does the same: https://portswigger.net/burp/help/proxy_using.html
So instead of
browser --(via https)--> server
Which only the server could read as only the server has the private key to decrypt the http so, it becomes:
browser --(via https)--> burp -- (via https)--> server
If you look at the https cert in your browser you'll probably notice it's been issued by Burp rather than being the real cert that the site shows when not using Burp.
This is the only real way of doing this, without majorly changing the browser to intercept it before the encryption happens, but can create its own problems: Should software really intercept traffic between you and your bank? What if that first connection can be compromised (see the Lenovo superfish incident for example). Many people (myself included) dislike MITM https services for this reason.
When using firefox I know that I can set the SSLKEYLOGFILE envvar,
and then provide the path to wireshark to decrypt the ssl traffic.
(https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format)
Is there a way to decrypt ssl traffic when requests are generated by apache httpclient?
Try running HttpClient with wire logging turned on as described here. This should be enough to see the exact composition of HTTP packets transferred over the wire.
I've got backend running on the tomcat server and client running in the browser. Application is built on Spring 3 MVC + Spring security framework. How to secure the communication ? Is there other option than just to set the server to be accessed only via HTTPS ? I've got no experience with this so it might be a stupid question, but will this affect my application and do I have to set something up in my app, when the server shall communicate with client via GET/POST request via https ?
It depends somewhat what you mean by "secure." If you want privacy, you must use TLS (SSL) as a transport.
If you're only concerned with authentication, then you have another option: Digest Authentication.
Digest Authentication allows the client (browser, usually) and the server to exchange authentication credentials in a secure manner without securing the entire communication. If you use Digest Authentication, then third parties can still:
See what data the client and server exchange
Insert themselves between the client and server and alter the exchange
What third parties cannot do is spoof the authentication or steal username/passwords in transit.
If that's not secure enough, you need TLS. You do not necessarily have to purchase a certificate. You can use OpenSSL to generate your own. This certificate will not automatically be trusted by browsers, however, so you can't really use it for public sites.
You will need to consult your server documentation for how to set up HTTPS or Digest Authentication, depending on which fits your needs.
Your application should not be affected by switching from HTTP to HTTPS, Tomcat handles this or maybe an Apache in front. It's important to understand, that HTTPS is a server-thing, not an application topic, because the client makes a connection to the server (Tomcat), not to your application. Check out the Tomcat documentation, it's pretty clear about how things work.
And, like the others said: From what you've said it's best to use HTTPS (TLS/SSL). Certificates are a bit frightning at the beginning, but it's worth to invest the time.
HTTPS is the (S)ecure form of HTTP, since you have an HTTP client server application I would certainly used HTTPS. All you need is to create an SSL certicate for your website and restrict access to your website to HTTPS only, then you are 99.99% secure.
Your certicate can be either commercial from Versign or equivalent or some open source engine.
for the clients nothing needs to be done to support HTTPS
I intend to have .NET thick clients running inside a Windows domain connect to a Java server via a straight TCP connection (protocol will be custom Google Protocol Buffer messages). I'm looking at how I can authenticate these clients without requiring further credentials be entered by the users (in other words, support single sign-on).
My initial thinking was to use Kerberos, but I'm not even certain that it's possible or ultimately secure over straight TCP. Can anyone comment on this? Is it possible? Are there any examples out there of how to achieve this, both client-side and server-side?
Kerberos doesn't run over 'straight TCP'. It uses an encryption protocol. See the JGSS-API, built into the JRE.