I must see the traffic from an android phone to a secure server using wireshark on Windows.
All packets are encrypted with ssl but i don't have the key, how can i find it?
Thanks
The key will be on the server. It depends on what software the server is running as to where the key will be stored or in what format. If it's an Apache server, then look in the ssl.conf file for SSLCertificateKeyFile. (Depending on the configuration, this may actually be stored in a different configuration file, you can grep for the string.)
Once you have the file, you can add it to Wireshark under the "SSL" protocol preferences. For more, see the SSL page on the wireshark wiki.
If you only have access to the client, it's possible to decrypt traffic using the pre-master secret, but it's a lot more inconvenient and you generally need to rework your client software to output it (and then it's only useful for that specific session; and if you have that, you might as well just have the client log its traffic in most cases). If this is your case, and you have a mechanism to get the software to output its pre-master secret (or can modify the software to do so), I can update the answer with more on that scenario. But if at all possible, avoid it and use the server's private key.
If you have lack privileged access to the client or the server, this is by-design not a solvable problem.
Related
Let say I have an application that should run on a VPS. The app utilizes a configuration file that contains very important private keys, in a sense that no one should ever have access to! I know VPS providers can easily access my files. So, how may I "hide" the sensitive data from malicious acts while still have them usable for the app?
I believe encryption will be of no help, since the decryption should be done on the same machine! Also, I know running my own private server is a no-brainier; but, that's not an option, unfortunately.
You cannot solve this problem. Whatever workaround you can find, there will be a way for someone with access to repeat the same steps. You can only solve this if you have full control over the server (both hardware and software), otherwise, it's a lost battle.
Some links:
https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html
https://owaspsamm.org/model/implementation/secure-deployment/stream-b/
https://security.stackexchange.com/questions/223457/how-to-store-api-keys-when-algo-trading
You can browse security SE for some direction, and ask a more target question.
This problem is mitigated with using your own servers, using specialized hardware for key storage, trusting to your host provider or cloud, and using well-designed security protocols.
But the VPS provider doesn't know how your app will decrypt the keys in the file? Perhaps your app has a decrypt key embedded in it, or maybe it is something even simpler. Without decompiling your app they are no closer to learning the secrets. Of course if your "app" is just a few scripts then they can work it out.
For example if the first key in the file is customerID, they don't know that all the other keys are simply xor'ed against a hash of your customerID - they don't even know the hashing algorithm you used.
Ok, that might be too simplistic of you used one of the few well known hashes, but if there are only a few clients, it can be enough.
Obviously, they could be listening to the network traffic your app is sending, but then that should be end-to-end encrypted already, if you are that paranoid.
I have a Ubuntu Server 12.04 that is accessible on the internet. Therefore, I would like to harden it a bit. I thought on starting to write a ~/.ssh/config file, forcing incoming clients a certain cipher, a MAC integrity, a key exchange algorithm, ...
Now my question is, which one is the best of them?
I thought on the following:
Ciphers aes256-cbc
HostKeyAlgrorithmy ssh-rsa
KexAlgroithms diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-96
What do you think, guys? Is this a reasonable way of securing?
The NIST/NSA Suite B set of protocols are generally considered to be the ones that you should be using. Here is a link:
http://www.nsa.gov/ia/programs/suiteb_cryptography/
Asking which cipher is the best, is a bit like asking which apple is the loudest - each set of ciphers have their merits and weaknesses, but at least the ones in this list are considered safe for government use. What you should be asking, is which ciphers have been proven weak (DES, MD5), and avoid them.
More importantly though, to harden your server, you should look at the following:
Possibly only allow key-based SSH authentication
Run SSH on a different port
Make sure you don't have any unsecured or guest users (or restrict SSH login only to specific users)
Make sure you don't have any other services running on the box (or at least restrict running services to the bare minimum required)
For securing/hardening ssh, I have found the recommendations available on at CIS to be helpful. While, I think they are selling tools and services, their benchmarks are free, specific, and rather helpful. The benchmarks are PDF reports that can be downloaded in exchange for your name, email, and a couple questions about who you are. I especially liked how they gave specific reasons for their recommendations, and references for more information. With respect to ssh specifically, and with respect to what crypto algorithms are safest, I found the CIS benchmark for Distribution Independent Linux to be particularly relevant.
With regard to using the ~/.ssh/config file to secure your server, this is not going to help. The ~/.ssh/config file sets preferences for how you (a specific user on your ssh client machine) will connect to any given server. So if you specify a short list of strong ciphers that may be used in your ~/.ssh/config, you are just telling ssh that when you log into a server, you will only accept the use of those specific ciphers. If those ciphers are not available, forget it! do not even connect to that server. The ~/.ssh/config file does not instruct your Ubuntu Server which ciphers to accept or not. The same goes for MACs, KexAlgorithms, HostKeyAlgorithms, etc. To configure your server, you want to take a look at the /etc/ssh/sshd_config file.
Finnally, if you are running an up to date version of your operating system, and you have an up to date installation of ssh and its configuration files, the defaults are fairly reasonable. I believe the ssh authors and maintainers, especially the openSSH authors and maintainer, know what they are doing, and they are specifically trying to provide tools that will allow you to safely, securely, and privately connect to your server using ssh. Having my own server publicly accessible on the internet, I too go through and check the options carefully. That said, as long as your server is running up to date software and using up to date configurations, and the only access to your server is through ssh, I believe you will be reasonably secure by just keeping everything up to date.
Here is my requirements:
Usable by any mobile application I'm developing
I'm developing the mobile application, therefore I can implement any securing strategies.
Cacheable using classical HTTP Cache strategy
I'm using Varnish with a very basic configuration and it works well
Not publicly available
I don't want people be able to consume my API
Solutions I think of:
Use HTTPS, but it doesn't cover the last requirements because proxying request from the application will show the API KEY used.
Is there any possibility to do this? Using something like a private/public key for example?
Which fits well with HTTP, Apache, and Varnish.
There is no way to ensure that the other end of a network link is your application. This is not a solvable problem. You can obfuscate things with certificates, keys, secrets, whatever. But all of these can be reverse-engineered by the end user because they have access to the application. It's ok to use a little obfuscation like certificates or the like, but it cannot be made secure. Your server must assume that anyone connecting to it is hostile, and behave accordingly.
It is possible to authenticate users, since they can have accounts. So you can certainly ensure that only valid users may use your service. But you cannot ensure that they only use your application. If your current architecture requires that, you must redesign. It is not solvable, and most certainly not solvable on common mobile platforms.
If you can integrate a piece of secure hardware, such as a smartcard, then it is possible to improve security in that you can be more certain that the human at the other end is actually a customer, but even that does not guarantee that your application is the one connecting to the server, only that the smartcard is available to the application that is connecting.
For more on this subject, see Secure https encryption for iPhone app to webpage.
Even though it's true there's basically no way to guarantee your API is only consumed by your clients unless you use a Hardware secure element to store the secret (which would imply you making your own phone from scratch, any external device could be used by any non official client App as well) there are some fairly effective things you can do to obscure the API. To begin with, use HTTPS, that's a given. But the key here, is to do certificate pinning in your app. Certificate pining is a technique in which you store the valid public key certificate for the HTTPS server you are trying to connect. Then on every connection, you validate that it's an HTTPS connection (don't accept downgrade attacks), and more importantly, validate that it's exactly the same certificate. This way you prevent a network device in your path to perform a man in the middle attack, thus ensuring no one is listening in in your conversation with the server. By doing this, and being a bit clever about the way you store the API's parameters general design in your application (see code obfuscation, particularly how to obfuscate string constants), you can be fairly sure you are the only one talking to your server. Of course, security is only a function of how badly does someone want to break in your stuff. Doing this doesn't prevent a experienced reverse-engineer with time to spare to try (and possibly succeed) to decompile your source code and find what it is looking for. But doing all of this will force it to look at the binary, which is a couple of orders of magnitude more difficult to do than just performing a man in the middle attack. This is famously related to the latest snap chat flurrry of leaked images. Third party clients for snapchat exist, and they were created by reverse engineering the API, by means of a sniffer looking at the traffic during a man in the middle attack. If the snapchat app developers would have been smarter, they would've pinned their certificate into their app, absolutely guaranteeing it's snapchat's server who they're talking to, and the hackers would need to inspect the binary, a much more laborious task that perhaps given the effort involved, would not have been performed.
We use HTTPS and assign authorized users a key which is sent in and validated with each request.
We also use HMAC hashing.
Good read on this HMAC:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
I'm attempting to set up a small network of computers where 4 child nodes feed small snippets of data into 1 parent node. I need the data transmission between the nodes to be secure (secure as in, if the packets are intercepted it is not easy to determine their contents). Does anyone have suggestions? I looked into HTTPS POST and encrypting SOAP messages, but before I got my hands too dirty I wanted to get opinions from the crowd.
HTTP over TLS is fine. And, since there is already quite a bit of tooling around it, it should be quite an easy and productive approach.
Besides TLS (SSL), which provides line-level encryption, you may want to authenticate the user using WS Security with X.509 Certificates. Another cheap security method is to limit traffic between hosts via by accepting messages only from known addresses/internal network hosts.
Again, HTTP over TLS (Formerly known as HTTPS) is secure enough for most security needs, and since th network packets already encrypted by HTTPS, you do not need to reencrypte your message (Unless you have an extraordinary situation).
I would suggest using TLS/SSL protocol.
There are some libraries available to implement this (depending on the programming language you are using):
-OpenSSL
-GnuTLS
-JSSE
-...
You also might want to check wikipedia on TLS/SSL for more information.
You probably want to look up TLS, which was built on its predecessor: the Secure Sockets Layer. Version 1.2 uses a combination of a MD5 and SHA-1 key.
SHA is one of the best one-way encryption algorithms to date.
You should also look into virtual private networks (VPNs), since it sounds like you need to maintain a secure session.
You could set up ssh tunnels, which (IMHO) are better for transmitting arbitrary data. The security is probably better since you can use public key crypto to secure messages. The system doesn't scale terribly well, but if you only have 4 nodes, this shouldn't be a problem.
What is the easiest free method of encrypting my web traffic? I'd like to be able to log in to sites on my web server without sending my password in plaintext.
Edit: My web server is running on the LAMP stack , although it is a shared host so I don't have root.
Get an X.509 certificate (for example, generating your own, or getting one free from StartSSL), and use it to set up SSL—a server-specific configuration task.
If you can't configure a new listener in your web server, there's not really a good option. In theory you could do a little hacking with some JavaScript crypto library, like JavaScrypt, and come up with something safe. I've toyed with several options but I don't know enough about it to come up with anything I feel confident about.
I don't know your circumstances, but if it were me, I'd consider another host.
https
Use a self-signed certificate.
Tell us your web server software for a detailed implementation description!
Since you don't have root your best bet is to contact your hosting provider and see what they can do for you. You may already have SSL access (try using https://yourdomain.com) using a self-certified key.
You should be able to talk them into installing a StartSSL key for you. This provides you with SSL encryption and browsers won't complain that it isn't signed by a valid Certificate Authority.
As stated above, publishing your own certification is free, however knowing more about your environment, may get you more specific answers. Are you running IIS? What will you be logging into that needs encryption? Are you using Windows Servers on the back end?
use Digest Authentication. Since you're on LAMP, you can configure it on Apache with mod_auth_digest.
Since you are trying to reduce costs, any ssl solutions will probably not be an option.
First it requires a signed certificate that cost a bit, the free ones is not always included in all web browsers.
Second to be able to utilize an ssl certificate your server ip must be dedicated to you. This is not the case in every cheap web hosting option. There are technologies that in the future will make it possible to host multiple ssl enabled sites on a single ip, but it's not here yet.
As mentioned before Digest Authentication is one option that doesn't require ssl certificate or dedicated ip.
It's a method of authentication that doesn't reveal your password even though everything else in the communication is unprotected.
In Apache this can be applied in individual directories by specific .htaccess files.
I'll repeat the previous link on mod_auth_digest.
This one is usually already installed on most servers so you won't have to ask you web hosting provider.
You don't always require root access to setup Apache to use SSL, but you will likely need to modify config files, which is either done thru your providers interface, or via files via a shell account. Either way you will need a server certificate; either self-signed, from a major company like Verisign, or one of the smaller free places like cacert.org. As noted by others, this does require a dedicated IP to your server or instance on the server.
I would recommend SSL first, but mod_auth_digest isn't a bad backup idea.