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.
Related
Here's the scenario:
Website A is served from a public domain example.com via HTTPS.
Website A needs to access a service B via WebSocket. Thus, the websocket also needs to be secure aka wss://.
The service B is currently not secured. I'm trying to secure it and I need to generate a certificate for it.
The service B is only available from the intranet. The WSS URL starts with wss://192.168.x.x (connecting by IP and behind a NAT). Yes, this also means that A can be fully used only from the intranet, although limited functionality is available through the internet. The typical case however is intranet use.
The computers which connect to website A aren't in a windows domain and do not currently trust any certificate authority that can be controlled by us. In other words, we cannot create a certificate that all these computers will trust by default. For that we would need to work with one of the large common authorities that everyone trusts, but I doubt they would issue a certificate for a NAT IP address.
The problem:
Since I cannot create a certificate that all the computers trust by default, I might as well create a self-signed certificate and use that to secure the websocket. However... I'm not really sure what will happen. I think that either the user will be prompted each time they connect, or the connection will fail silently anyway.
I can manually install the certificate on each machine, but that requires visiting them each separately, and if a new person wants to access the website, I need to remember to do it on their machine too. Not nice.
Is there some good solution to this? Can you make a website prompt for permanently trusting the certificate or something?
Most browsers have a built in function for permanently trusting unknown certificates, and, to be frank, I wouldn't trust any website, that tried to circumvent those mechanisms, even if they were intranet sites. If something like that appeared while visiting an intranet site, I would be more inclined to call IT Support and ask, if the website has been tampered with.
I would distribute instructions on how to add the certificate (maybe noting that mindlessly doing this on other websites than yours might be problematic) and deal with the cases that are unable to follow these instructions.
An alternative (although I don't have any personal experience with that) might be getting a free certificate from https://letsencrypt.org/ which, as far as I know, will be accepted in most browsers.
Firefox:
Chrome:
https://www.accuweaver.com/2014/09/19/make-chrome-accept-a-self-signed-certificate-on-osx/
At the moment I'm running towards the same problem only solution I can think about and what I'm trying is that I ask the user to click a button (which creates a pop-up window) with the webserver with the certificate which needs to be accepted. Then they accept the certificate and I ask them to reload (or restart the code by clicking the same button) then it should be able to work. But you will need a page on the w
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.
I'm looking for some info about securing a website. The website is actually a kind of management console that can be accesses through a web browser. The console is currently only available on the internal network, but I want to make it accessible through the internet, only for some specific users/devices.
The first problem I faced is that the management console didn't provide authentication at all. To overcome that problem, I've installed apache, which I use as a (reverse?)proxy and in which I enabled basic authentication, so now I have to enter a username and password before I can access the console.
The thing that I want to do next is to prevent the username and password to be send over the line as plain text (I assume that's whats happening now). I think I have to make it a https connection for that, but I find so much information about that so that I'm a bit lost on how to continue. Can I make this work with self signed certificates or do I need to buy certificates somewhere?
You are right about securing passwords through https. I would suggest redirecting everything on your server through https, following this article.
I would suggest testing the whole solution without buying anything. Buying a certificate means that it would be bound to your server. I suppose that when you develop your solution, you use a development server. If you buy a certificate for your development server, then you would have to buy another one for your production server. Therefore, I would use a self-signed certificate for development and when the application is ready to go public, then I would buy a certificate recognized by all browsers.
In order to create a self-signed certificate you could follow this tutorial supposing you work on linux, or this tutorial supposing you work on windows.
Hope I helped!
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.
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.