I'm working on changing the cipher specifications on a number of web servers that I manage, to avoid the BEAST/BREACH/CRIME kerfuffle that everyone's talking about.
On our LAMP hosts, I simply upgraded to OpenSSL 1.0.1 and Apache 2.4, and used these cipher specs:
SSLCipherSuite
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA384:ECDHE-RSA-RC4-SHA:AES256-GCM-SHA256:RC4-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:AES256-SHA256:AES256-SHA128:AES128-SHA128:AES256-SHA:AES128-SHA:!MD5:!NULL
Which function as I want -- compatible clients generally get the cipher spec from the topic, and hopefully in the future TLS 1.2-compatible clients will get the GCM suites, and everything fails pretty gracefully. However, we have some very important ASP.NET apps running in IIS 7.5 on Server 2008 R2 (fully patched), and the group policy "SSL Cipher Suite Order" does not seem to support this.
In Server 2008 R2, in the group policy for cipher suites, it lists supported ciphers. Apparently it only supports GCM ciphers for ECDHE_ECDSA, not ECDHE_RSA. Only CBC is supported for ECDHE_RSA. Also, there is no listed support for combining ECDHE_RSA with RC4.
Am I missing something, or is there a good workaround? All I can think to do is proxy it through a host which does support the encryption I want, but that is not desirable for a number of reasons. Am I stuck using regular RSA-RC4-128-SHA? Or if I disable HTTP/TLS compression, and take the performance hit, can I use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 or similar safely?
Sorry if this doesn't make much sense, I'm pretty new to this sort of thing.
Related
SSL Labs is great for identifying weak cipher suites. But how do I know how many clients I affect if I remove them?
Is there a way to log on the server side which TLS version and cipher suite was being used for each connection?
Where do I look? Is this information available to the server software, or is it only available further down in the network stack?
The specifics
The case that triggered this question is a BI tool (Qlik Sense) behind an Azure Gateway.
But when I thought about it, I can't remember seeing this kind of information in any other systems either.
To turn the question around:
If I follow SSL Labs recommendation, and only allow TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:
What systems do I then exclude?
(How do I know if there are any at all, or lots of them?)
Apology
Sorry for a very open ended question. But I really don't know where to start looking. Please let me know some key issues, and I can rephrase the question to more specific.
We're developing a mobile application with Xamarin which will operate on Android and iOS initially, with plans to port to Windows phone in the future (if the 3 people who use it scream loud enough).
The nature of the data being transmitted and the actions that this application will allow (SSO into another read/write system) we want to take every step we can to secure the data transfer layer as much as possible.
Naturally this takes us down the path of SSL/TLS Certificate Pinning (in addition to other mitigations in the API calls themselves) to protect the clients from connecting to MITM proxies and the like.
We operate the API endpoint and have complete control of the certificates and thus we are comfortable with storing public keys in the app to pin to, as we will be able to update our certs and deploy with new pins in sufficient time. All certificates are valid 3rd party signed certs (not self signed).
Unfortunately it appears that doing the SSL Pinning with Xamarin is not performed very often, as we've found it difficult to find implemented examples.
OWASP provide some .NET sample SSL Pinning code which uses ServicePointManager.ServerCertificateValidationCallback to provide a callback to check the SSL pin; but doesn't specifically mention it working under Xamarin.
Additional Google searches for this code often returns people using it to do the exact opposite of what we're wanting - they use it reduce the SSL certificate checking, not increase it!
I can see one answer which suggests this approach works OK Android and iOS - but I'm most interested in specific experiences in around using this in Xamarin, specifically Xamarin.Forms, to pin SSL/TLS Certificates.
I have validated that SSL/TLS Key Pinning works on Android (though only in an emulator at this point) using ServicePointManager.ServerCertificateValidationCallback
I am writing a client application that needs to send a file via BITS to my server. I have everything working for the most part, but I can't get the BITS connection to operate securely with HTTPS.
Right now I'm just using basic authentication through HTTP, so the login is being sent cleartext--which is not optimal :-) I would like to be able to use HTTPS, but am not sure how to go about doing this. According to this Google Groups thread, BITS "doesn't support authentication using certificates" (though that comment is a few years old now). Does this mean SSL is out? How else can I secure a connection for BITS via HTTPS?
My server is running IIS 6.0 on Windows Server 2003. Any help would be greatly appreciated!
BITS version 2.5 supports certificate based client authentication. Check which version you have installed and potentially upgrade it to the latest.
Note sure if this is the latest, but here's a starting point:
http://support.microsoft.com/kb/923845
BITS supports HTTP and HTTPS protocols. So if you have an SSL cert installed on your server and also installed in the Trusted Store on you client then I believe that BITS will work over HTTPS without any more intervention.
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.
I have a client who is in need of a file based encryption / decryption application to be used between Linux / Windows 2003 Server. The goal is to have a single file compressed nightly on a linux platform and secured using a script, transmitted over FTP, decrypted on the Windows 2003 server and available for other import routines such as SSIS, etc.
The file can remain unencrypted on each end after transport, the desire is mainly to keep the file secure during transport. Firewall rules and the fact that IIS6 doesn't support SFTP eliminate SFTP as an option. Simplicity is the primary focus here, so complex security options or heavyweight libraries cannot be used.
You could try GnuPG, it's cross platform and since you are only sending files internally you don't really need a certificate signed by a big-name certificate authority.
Also you can use our OpenPGP task for SSIS when you need to load the protected data into SSIS.
You could look at PGP:
http://www.pgpi.org/doc/overview/
http://www.pgpi.org/products/pgp/versions/freeware/
http://www.pgpi.org/doc/
To GnuPG I would add Thawte (or similar) s/mime keys for email.
GnuPG has executables for every major platform and most email clients support s/mime keys for encryption.
Try R10Cipher.
Cross Platform,
384 Bit,
Handles Text and Files,
Very Simple to use and inexpensive
http://www.r10cipher.com
Disclaimer: It's produced by my company, Arten Science.