We want to implement https to our website. But given that our team have no experience with https/ssl things, it will take us a bit time to learn how to use encrypted connection on our website.
We want to make our website the more secure as possible during the time we try to implement an SSL certificate.
So, we heard about a temporary solution we could use. Something like to ask the user (With a popup confirmation) each time he goes our website if he want to use a secure connection (Like a new certificate for each connection to our website).
I don't know anything about this "method", I don't even know what to search on google.
Is this even possible ? If yes, how you call this ?
You probably refer to self-signed certificates as the temporary solution.
To implement them you already have to implement https at your server and the only difference to "real" https is that you don't buy a certificate from an established CA, but that you create your own. In this case the browser will not trust the certificate by default and need to ask the user to trust the certificate. Of course, not all users will simply trust some stranger so expect to loose more users of your site this way than you would loose if you don't use https at all.
Related
I have looked at about 10-15 different pages about the SSlStream class and about certificates and I haven't found one that completely explains everything to me. So I have a bunch of questions.
I am currently working on some SslStream code and I have a question about certificates. From my research it appears that the server requires a certificate if we are using TSL12. And it appears optional that the client needs a certificate.
1) Now if we design a system that the client needs a certificate do we use the same certificate for the client and the server? Or do they both use different ones?
2) Also looking at the Microsoft SslStream help page:
https://msdn.microsoft.com/en-us/library/system.net.security.sslstream(v=vs.110).aspx
How does the code know if those are the expected certificates?
3) In the Property page on a project under Signing you can Create a Test Certificate. When you click that button it asks for a Password. If a password is used how would that affect the SslStream code? The code on the Microsoft help page above doesn't deal with that at all?
4) Once I have a certificate for the server and the client can I just place them in a directory or do I need to put them in the store?
Thanks.
You can find most answers to your questions here
These are the different certificates. Client certificate used to check client identity. Server certificate used to encrypt key materials and to authenticate itself.
What means expected? You mean whether the client certificate is correct? You can write your own login to check client and certificate. By default expiration date is checked, where it's revoked or not etc. Read there to clarify.
It will create certificate and to use private key you will need to provide password to get it from storage
The base usage is to put it into the store. But you can also get it from .pfx file. You can read there about geting the key from file
1) Now if we design a system that the client needs a certificate do we use the same certificate for the client and the server? Or do they both use different ones?
The best practice is "one certificate per purpose". Think of a server authentication certificate as the "Warner Bros. Studios" sign hanging on the building as you pull up to the guard shack, and a client authentication certificate as an employee ID badge. They both inform the other party what's going on, but it feels a little out of place to then walk down the street to Universal and show your big Warner Bros. sign as identification.
2) Also looking at the Microsoft SslStream help page: https://msdn.microsoft.com/en-us/library/system.net.security.sslstream(v=vs.110).aspx How does the code know if those are the expected certificates?
The server authentication certificate you provide is correct, because you provided it.
If you give only one client auth cert, that's correct, because you provided it.
If you give multiple client auth certs then it will use an acceptable CAs list provided by the server TLS handshake to reduce the list, then it takes the first one that was acceptable.
3) In the Property page on a project under Signing you can Create a Test Certificate. When you click that button it asks for a Password. If a password is used how would that affect the SslStream code? The code on the Microsoft help page above doesn't deal with that at all?
Certificates don't have passwords, but PFX/PKCS#12 files do. You need that password to load the file into an X509Certificate2 instance (e.g. new X509Certificate2("servercert.pfx", "1Potato2Potato3Potato4")). Since SslStream won't do the loading for you, it doesn't talk about passwords.
4) Once I have a certificate for the server and the client can I just place them in a directory or do I need to put them in the store?
They should work fine when loaded from a PFX (you need the private key, so it can't be just a .cer). If the certificates can be one-time loaded into cert stores you can avoid the problem of loading or hard-coding PFX passwords... but that just depends on your deployment needs.
I am part of an indie game developer team and we are working on a project in Unity (C#).
I used Drupal on the backend (PHP/MySQL) and I want to retrieve data from the database to our software.
So for example if I want the user to log in via Drupal's authenticate (server sided hashing of sent passwords), the user needs to submit his username and password via unity WWWForm or c# HttpRequest at first (client).
If I've done my research properly, there are three possibilites to send data securely (please correct me if I'm wrong):
Implement own password encryption/decryption (use Drupal's password hashing after server side decryption)
Implement drupal's hashing method(s) in c# (client)
Buy SSL certificate and go with HTTPS
It's possible to sniff the HTTP connection or decompile the software, right? Do possibility 1) and 2) make any sense then? Would one of the two methods be secure enough?
Is SSL the only way for us to go?
Implement own password encryption/decryption (use Drupal's password
hashing after server side decryption)
Implement drupal's hashing
method(s) in c# (client)
The problem with these methods is that the client side hashed version effectively becomes the password. So if a MITM grabs the hashed version, they can simply replay it to log in.
Buy SSL certificate and go with HTTPS
Definitely. As well as encryption, HTTPS provides assurance that the client is talking to your server and this hasn't been MITM'd and it will also protect against replay attacks (an attacker recreating the login request from their own connection and then acting on the response).
It depends how secure you want things, and how far you believe an attacker would go to intercept a password. For example, if you use client-side password hashing via JavaScript, it is theoretically possible for the JavaScript library to be intercepted as it travels to the user, and modified so that it sends a plaintext copy of the password. This can then be intercepted as it is sent to your server. But, since you are working on a computer game, this may not be very likely to happen.
SSL with a genuine certificate would go some way to preventing this, since it is theoretically impossible for a MITM (man in the middle) attack to sniff, never mind modify, data as it travels down the wire. To do that, they would need to have a copy of your private server key, either by stealing it from your server or stealing/obtaining it from the certificate authority. While this is not impossible, it is most unlikely to happen.
SSL certificates of the lowest security are now very inexpensive, and in general will save you a lot of work thinking about how to implement security. I'd just go with this option.
I asked a question here a while back on how to hide my http request calls and make them more secure in my application. I did not want people to use fiddler 2 to see the call and set up an auto responder. Everyone told me to go SSL and calls will be hidden and information kept safe.
I bought and installed an SSL Certificate and got everything set up. I booted up fiddler 2 and ran a test application that connect to an https web service as well as connected to an https php script.
Fiddler 2 was able to not only detect both requests, but decrypt them as well! I was able to see all information going back and fourth, which brings me to my question.
What is the point of having SSL if it made zero difference to security. With or without SSL I can see all information going back and fourth and STILL set up an auto responder.
Is there something in .NET I am missing to better hide my calls going over SSL?
EDIT
I am adding a new part to this question due to some of the responses I have received. What if an app connects to a web service to login. The app sends the web service a username and a password. The web service then sends data back to the app saying good login data or bad. Even if going over SSL the person using fiddler 2 could just set up an auto responder and the application is then "cracked". I understand how it could be useful to see the data in debugging, but my question is what exactly should one do to make sure the SSL is connecting to the one it was requesting. Basically saying there cannot be a middle man.
This is covered here: http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp
Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates a HTTPS certificate.
Essentially, you manually trust whatever certificate Fiddler provides, the same will be true if you manually accept certificate from random person that does not match domain name.
EDIT:
There are ways to prevent Fiddler/man-in-the-middle attack - i.e. in custom application, using SSL, one can require particular certificates to be used for communication. In case of browsers, they have UI to notify user of certificate mismatch, but eventually allow such communication.
As a publicly available sample for explicit certificates, you can try to use Azure services (i.e. with PowerShell tools for Azure) and sniff traffic with Fiddler. It fails due to explicit cert requirement.
You could set up your web-service to require a Client-side certification for SSL authentication, as well as the server side. This way Fiddler wouldn't be able to connect to your service. Only your application, which has the required certificate would be able to connect.
Of course, then you have the problem of how to protect the certificate within the app, but you've got that problem now with your username & password, anyway. Someone who really wants to crack your app could have a go with Reflector, or even do a memory search for the private key associated with the client-side cert.
There's no real way to make this 100% bullet proof. It's the same problem the movie industry has with securing DVD content. If you've got software capable of decrypting the DVD and playing back the content, then someone can do a memory dump while that software is in action and find the decryption key.
The point of SSL/TLS in general is so that the occasional eavesdropper with Wireshark isn't able to see your payloads. Fiddler/Burp means that you interacted with the system. Yes, it is a very simple interaction, but it does require (one) of the systems to be compromised.
If you want to enhance the security by rendering these MITM programs useless at such a basic level, you would require client certificate authentication (2-way SSL) and pin both the server and client certificates (e.g. require that only the particular certificate is valid for the comms). You would also encrypt the payloads transferred on the wire with the public keys of each party, and ensure that the private keys only reside on the systems they belong to. This way even if one party (Bob) is compromised the attacker can only see what is sent to Bob, and not what Bob sent to Alice.
You would then take the encrypted payloads and sign the data with a verifiable certificate to ensure the data has not been tampered with (there is a lot of debate on whether to encrypt first or sign first, btw).
On top of that, you can hash the signature using several passes of something like sha2 to ensure the signature is 'as-sent' (although this is largely an obscure step).
This would get you about as far in the security way as achievable reasonably when you do not control (one) of the communicating systems.
As others mentioned, if an attacker controls the system, they control the RAM and can modify all method calls in memory.
I'm building a system that consists of many clients connecting to a server. The clients automatically push data to the server via a web service call.
I've built an authentication mechanism in order for the clients to authenticate with the server so only authenticated clients can upload data.
The problem is that I've hardcoded the password into the client code and it is accessible if someone uses a reflector.
In this scenario, where I have no user input, what would be the best way to store the static password on the client?
Thanks
(.Net version on the client is 2.0 and the .net version on the server is 3.5)
You have a number of methods that you can use, but one of the easiest to implement would be to encrypt the password and then just store it in the app.config for the application that gets deployed to the user.
Have you looked at http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.aspx?
Also, are your webservices WCF? If so, you could use mutual certificate security. It is much more robust than a password.
HTH
"I've built an authentication mechanism in order for the clients to authenticate with the server so only authenticated clients can upload data."
How are they authenticated to become "authenticated clients"?
Can someone just copy your application to their home computer and now they are an authenticated client?
This seems like a huge security oversight if you're trying to decide who can upload based on a value in your assembly.
If you can do IP based validation, if you want to avoid passwords and login mechanisms.
I would consider getting a good obfuscator for your code, for one thing. That will prevent (or at least deter) people from using reflector on your assemblies.
However, your authentication system doesn't sound too secure. Even if you did encrypt the password, if the password is always the same, it would be as easy as sniffing packets to figure out what needed to be sent to your server to authenticate. Because it would have to be decrypted before it was sent.
You'd have to go over an SSL at the very least.
Also you might want to look into using Asynchronous Encryption with Signed XML using a Machine Hash if you're installing this in some public client's environment. Something like a Licensing Scheme.
I don't know anything about your architecture or the environment you're running in, so I can't make any recommendation as to what would be the best security implementation, but I can tell you the current setup doesn't sound secure to me.
I'm currently working on a project that requires encrypted data be passed between WCF hosts. As I understand it there are only 2 ways to ensure that data passed over WCF is secure.
Using Certificates
Using a Domain (or having the same username and password on every machine on the network)
Using certificates can be expensive and complicated to manage and since we're not guaranteed to have a server class machine at every deployment a Domain is also out of the question. Having every machine use the same username and password is also problematic if that password ever needs to be changed.
Currently we use OpenSSH to tunnel our connections between hosts. Is there another option built into the framework that I'm unaware of?
Encryption requires a key. Keys are usually implemented as certificates. If you own both sides of the communication, you can create your own certificate for free without having to go buy one from a trusted root authority.
Here is an alternative. Works without IIS and SSL/X509 certificates.
If you are using a http endpoint, you can use a secure transport such as https.
Use traditional encryption of the data that you are placing inside the WCF container. Maybe something like the following:
http://www.obviex.com/samples/EncryptionWithSalt.aspx
The cheapest method is probably to run your own certification authority. This means you have total control over the certificates, but you do not have to pay for external certification. If you automate this appropriately, you can give every machine on your net a cryptographic identity and use your local certification to tie everything together.