I'm working in a Java (Android) project, the main idea is to capture urls and block the access to dangerous pages, so to obtain the urls that the user access I'm using pcap4j library as follows:
IpV4Packet ipV4Packet = packet.get (IpV4Packet.class);
Inet4Address srcAddr = ipV4Packet.getHeader().GetSrcAddr();
System.out.println(srcAddr);
So if I access the url (https://es.wikipedia.org/wiki/Google) the code will generates the domain name, something like : (wikipedia.org), but what I really need is the main url that generates the request, How can I get the complete URL (https://es.wikipedia.org/wiki/Google)?
It's really difficult I think.
In order to get the URL, you need to see the request line of the HTTP packet.
But Pcap4J now doesn't support HTTP, so you need to write packet classes to dissect HTTP packets.
And, HTTP is on TCP, which usually fragments upper layer packets.
You need to reassemble HTTP packets before you can dissect them.
And more, if https, the HTTP packets are encrypted and fragmented by TLS layer. In this case, you need to reassemble and decrypt the HTTP packets to get the URL.
To decrypt TLS packets, you need the secret key of the HTTP server.
But, even if you have the key, you can't decrypt the packets when Diffie-Hellman key exchange algorithm is used in the TLS session.
Related
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.
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.
As we now, a .jar file, we can open it and see the code and classes with any decompiler. Now suppose the following situation:
I developed a Client-Server application under JAVA, in both Client and Server, i used AES-256 for encrypting the data sent over internet. So, i give the "Client" to my friend. Now.. The question is... can he hack my Server knowing how are the packets received in the Client, treated, and sent back? I mean... encrypting the data when you have a revealed code, it's.. in vain, doesn't it?
The question is... what can i do to have the best security possible in the Server? does encryption work in this case ?
Thanks !!!
Don't use encryption just to hide how your client-server protocol works. If you want your server to be secure, make it secure even when the client is in full control of what goes on.
As you've mentioned, it's easy to control the client: not just via decompilation, but also by running the client in a debugger (which can modify the contents of any object, modify control flow, etc.).
My points, then, are:
It's important to identify where the potential attack vectors are in your server, and address those. For example, if you want to be able to send a cookie to a client, which you want them to send back unaltered, you don't need encryption for that; just use HMAC.
If you actually really want to encrypt traffic between client and server, don't use straight AES (especially because it sounds like you're using a fixed key, which is insecure). You want to use a protocol designed for wire encryption, like TLS (SSL). Yes, really use TLS (including acquiring a certificate from a certificate authority); don't take shortcuts.
The nice thing about TLS is that there are no shared secrets (such as keys) that you have to embed into your jar. So there is nothing you have to worry about hiding.
If by him hacking your server you mean him meaning figuring out the protocol and contents of the packet that goes in, and then sending funky packets to make your server do unexpected things at unexpected times, the solution seems to be not as much encryption but strong validation. That is, your server should expect only a limited set of values in the incoming packets at each step of your protocol, and if some of the incoming packets do not conform to this/attempt to do something unexpected, they should be discarded.
Your encryption is not going to allow you to hide the protocol/API/etc. that the client and server use to communicate with each other. By encrypting the data flowing between the client and server, you are preventing someone that is observing this traffic as it passes across the wire (presumably the internet) from snooping on the data.
One issue to keep in mind is that AES requires a password that is know by both the client and the server. If your password is hardcoded in the jar, then anyone that has the jar can snoop on any traffic between your server and anyone's client that connects to it. So, you need a secure way for the client and server to agree on the password to use for a given connection.
I suggest using an SSL-based technology for encrypting the data going on the wire (e.g., maybe you can simply use HTTPS as your protocol). Or perhaps use public key encryption.
It is hard to make a specific recommendation, given the lack of information about the communication pattern between client and server.
I have a REST API which clients connect over SSL (self signed cert 2048bit)
I was thinking of implementing the following security
The client requests a RSA public key from the server
Encrypts the username / password
Adds these to the header of EVERY REST call allowing the server to be stateless
The application involves users adding credit cards (the numbers themselves are encrypted) and purchasing products so security is critical
We also have very limited time from a iphone client point of view so I was hoping if the above would be suitable?
Usually, when it comes to security, one doesn't want to reinvent the wheel. It's way better to use state-of-the-art technologies, so you'll benefits from others' (likely more skilled than you) work.
If you have a RESTful API on SSL, I don't think you have written your own custom TCP protocol. Likely you'll use HTTP, so since it's on SSL, you are on HTTPS.
When using HTTPS, your browser makes sure that the request is signed and encrypted so that only the other end (the service) can authenticate the client and decrypt the message. So there is no need to encrypt data and using custom headers. A simple cookie-based session is enough so you don't send users' passwords in every request.
I am concerned that the data that is being sent from our remote database to the java based client software is not being sent securely as it is using http tunneling with RMI rather than https.
The problem is I need to prove the vunerability to my boss before he takes it up with the IT company.
How can I send and receive data to an RMI cgi serverlet to test this theory?
I have used wireshark to see the packets and I can see the url that the data is POSTed to but have no idea of an easy way to replicate the RMI protocol (without writing a whole Java app).
I believe that you can create special method with simple signature like
String foo(String);
Now try to call this method with your mechanism and user wireshark to catch packets. I think that if the data is not encrypted you will be able to see the parameter and return value in clear text.