Note: I am working on this as a learning exercise and not for using on an actual website.
I am trying to learn additional ways I could explicitly or statisticly identify a user so I could look at having a sort of "confidence scale" on how securer a users session is. So I could ask the user to re-verify their email if it looks like the password or authtoken has been leaked.
If a client is using a securer https connection then I believe that connection would be encripted in a way that is unique for that connection, and I'm interested in testing and trying to understand better how that information could be gathered and how it could be used.
So, Is there a way to collect the information exchanged during the server clients TLS handshake process on the web server?
I've been testing using Node.js at the moment, but would be happy to try a different langauge or software just to test this out.
Does anyone know if the client details would only be unique for the connection, or if they should be unquie for the browser or device or network interface? (For example if a mobile device goes from wifi to mobile data and the IP address changes Does the HTTPS handshake happen again wit the same or different values?)
And does anyone know if doing something like having multiple certificate for the domain and serving different certificate to differnt users would change the clients default responces on reconnections?
I would assume that the client could probably be identified by loading unique sub domains with unique certificates, and measuring timings to see what certificates in the certificate chain had been cached, and would like to test this, but also not sure if there would be a simpler or easier way?
Related
Can a website check in the application layer which key/certificate the client is using?
Somehow detect that the certificate is not the real one, but issued by Sneakycorp Inc. because a man-in-the-middle attack is in progress.
I realize that the mitm could fake the response, but that raises the bar for simple copying proxies.
I see two possibilities:
Use code on client side
Use code on client side (e.g. JavaScript) to read the used certificate and send the info back to the server. Then on server side you could compare if the used certificate is the expected one.
It seems like in JavaScript it is not that easy to get the necessary info on the certificate. The used method in the linked answer seems to be Firefox only at the moment.
TLS fingerprinting
A second way is used by large content delivery sites: HTTPS fingerprinting
Based on the TLS headers you can generate a fingerprint on TLS stack and often also on the used technology/run-time and OS like .Net, Java, Python, and so on. If you then compare that with what you expect e.g. based on the user agent you can calculate the chance that you have a direct connection or if some man-in-the-middle server is active.
I have an android app with few apis that has SSL. When i try to do packet sniffing using Fiddler2 or charles proxy after installing a trusted certificate on my device, I've been able to see all HTTPS calls.
I made a few tests in other apps to see if its normal and found some of them won't show or connect to the ssl request. How can i avoid being showing my APIS on packet sniffing. I am using lets encrypt on my domain for ssl
This is not possible and it also shouldn't be necessary.
It is impossible to tell whether a device along the path between client and server is sniffing packets. Thus you will not be able to kill the connection based on whether someone is sniffing somewhere. This is the equivalent of looking at a downloaded file on your computer and wondering how many other copies there are in the world. Neither the file nor your receipt thereof stores this data.
It should also not be necessary as HTTPS is immune to MITM provided you are not a state-level actor. This is unless you have access to the client, in which case you can add your MITM as a trusted CA. For more info on HTTPS and MITM attacks, you should take a look at Kazakhstan's past attempt at it
I am building up a small iot-like system, where mqtt devices(clients) are sending and receiving security-related critical information or commands.
I have got to know that TLS connection can be built optionally without client authentication thru PK certificate on the client side.
Normally, mqtt client devices don't have enough resources to support PKI, where at first it has to store a certificate and from time to time, to update it with newly issued ones when validity has passed or when the original certificate has been revoked.
That was, I think, why many of mqtt brokers have an option to configure on/off the client authentication during TLS handshake.
However, my concern is if there would be any security issue from passing the client authentication step, like, for example, a chance that some other malicious devices impersonating one of my devices can connect to the broker could obtain those critical information and commands.
My question is what best options and practices I can take to minimize that kind of risk considering the constraint resource of devices.
Missing client authentication means that everybody including an attacker can claim to be a valid client. There can be use cases like public services where this is not a problem and there are other use cases where the server wants to restrict access to specific known clients only.
There is no definitive answer to this question, it will always depend on the following factors, and only you as the designer can answer them:
What is the threat model you are working with? E.g. Who are you trying to keep out of the system and why, what are the consequences of somebody connecting a rouge client?
How much are you prepared to spend? If you intend to deploy client certificate or even a unique username/password for each device, how will it be protected? Does the hardware you intend to use support a secure enclave/hardware secret store? Meaning how hard would it be for an attacker to extract the client username/password or secret key from the device?
What other security measures do you have in place? Do you have Access Control Lists to protect which topics a client can publish/subscribe to? Do you have monitoring in place to detect malicious actions from clients so they can be disconnected and banned?
I have a small device that contains a client program which communicates with a server over the internet. Pretty standard stuff.
I have a requirement that the server be able to authenticate messages coming from the device, meaning that all communications from the device be from the authentic client and not from some impostor. It's assumed that an attacker can reverse engineer the client and also load his own programs onto the device.
I'm questioning whether this is even possible. I could certainly load a client certificate into the client, but an attacker could get to this and use it himself. The cost of the device must remain low, so no fancy hardware tricks. Any ideas on how I could do this?
Depending on the device, and what kind of abuse you are talking about, you could use a scheme that needs some kind of activation. Like entering a master key into memory only - so its lost if power is lost - a technic used on some crypto cards.
A way to counter stolen devices could involve some kind of lease of keys that needs renewal on a regular basic by specifying a secret.
A way to counter an imitation/copy could be to works with a common state between the client and server that keeps changing. Like negotiating new encryption keys regularly.
We use a similar thing with our apps and web services. We call it ApiValidation where the client in each request to the service adds a header called ApiID which the server can decode to see if the client is authorized or not.
My scenario:
Many WCF clients which are in environments outside of my control
Server will either be mine OR in an environment outside of my control
So worst case the client and the server is outside of my control. More specifically, I might assume that someone hosting this code could try to maliciously impersonate either the server or the client (the server being more likely). However, the client needs to verify that the server is my code and the server needs to verify that the client is my code. I've seen all the recommendations to use certificates; however, is that an option given my scenario?
One approach I've considered is to write an IClientMessageInspector and an IDispatchMessageInspector to set and verify a custom SOAP header on both sides. I would create an HMAC signature based on a secret key contained within the source code (assume I have a way to keep this hidden) and then verify the digest based on the message body.
I feel like this would work; however, I feel like there might be something more out-of-the-box that I'm missing here. Am I close, way off track? Thanks for any guidance!
Certificates are definitely the way to go in your situation.
Your server will easily be authenticated by clients because it will provide a certificate known to each client, SSL is a good option here.
The server will also be able to authenticate clients by requesting that every client should provide a certificate (server can check for a specific issuer of the certificate - your own issuer in that case).
Now you just need to correctly manage/secure your certificate server to make sure that it won't be compromised.
I don't think there is anything out of the box to do this, simply because it is an unusual requirement for the server to verify that the code on the client calling the service is authorized code.
Generally, it is sufficient to establish trust as follows:
Server has a certificate and service uses SSL - this way clients are confident that they are connecting to the correct server machine.
Clients provide authentication details (eg username/password, certificate etc) to the server so the server knows the connecting client can be trusted.
You are attempting to go the extra step to verify that not only are the users/machines verified, but also that the code running is verified - this is simply overkill. If the code running is not verified, either:
One of the machines has been compromised, in which case you have bigger issues to worry about.
One of your users has written code against your service and is using it 'illegally'. This should not be a problem if your service only allows authorized users to perform 'dangerous' operations.