I've just recently learned a bit about how encrypted messages are sent across the Internet, and it seems that it relies a lot on "trusted third parties" My problem is that I don't trust anyone, is there some way to form an encrypted connection between two computers without prior secrets or the need to trust anyone?
Yes, by creating a "Certificate Authority" (CA) and installing its certificates on the machines.
The third parties you're talking about issue certificates, and sign those certificates using a CA certificate that is included in popular operating systems and/or web browsers. You can create your own CA certificate and install it onto the machines in question alongside those third party certificates. Then you can issue your own SSL certificates which will be recognised by those machines without any third party involvement.
Note that the CA certificates aren't "prior secrets" - there's nothing secret about the certificate itself. It has a private key, which you use to sign your SSL certificates, but that key doesn't need to be on the machines in question (and shouldn't be).
There are plenty of sites that will walk you through the process - a quick Google turned up this one for example: Creating Your Own SSL Certificate Authority.
Related
I'm building my first web app and I have two questions about security.
I'll send and receive very sensitive data with POST request to my
api which will be hosted on Azure or AWS. Can I send and receive
data in plaintext over SSL, is it secure? I can access my
azure web site over https, is it secure enough or should I buy another
SSL sertificate?
I've searched a little bit and there are different types of SSL
certificates, I read some certificates provide green padlock or green address bar but I don't need these kinds of things since my web app only
will be available to my mobile app and there will be no content to browse. Only one page with download links to my mobile app in case someone finds this site. So all certificates are secure on same level for my situation?
P.S. I won't add custom domain name, if that's relevant.
Answering your questions one at a time;
Modern implementations of SSL are generally considered to be pretty
rock-solid; its used by banks, healthcare institutions, and major
internet companies. Sending data in plaintext, over SSL, is
safe enough for those applications, and trying to replace SSL with
your own encryption scheme is almost certainly more trouble than its worth.
You should probably get your own SSL certificate; I don't know what restrictions Azure has on https access, if any, and its always bad practice to rely on a key you cannot control.
SSL relies on networks of trust; browsers (and other internet applications) validate the certificates sites send them against a
set of trusted authorities. If the certificate has been approved
(signed with the authority's private key), the browser accepts the
certificate as genuine and uses it to negotiate an SSL connection
with the site without further complaint. This is what that green
padlock/address bar means; that a site has provided a valid
certificate signed by an authority the browser trusts. This doesn't
mean that a signed certificate is inherently more secure than an
unsigned certificate, however. Both use the same cryptographic
algorithms, and (can) have the same length keys, and the SSL
connections each can set up are equally secure. The difference
between the two is that you can't verify the "authenticity" of an
unsigned/self-signed certificate; an attacker could intercept the
connection and replace an unsigned certificate with their own
certificate, and the browser would have no way of telling if it got
the right certificate or not. You can overcome this problem in your
application, however, with a technique called "certificate
pinning".
Essentially, you package the public key for your certificate with
your application, and your application only accepts the certificate
associated with that key when setting up a connection.
Ultimately, it depends on your attacker model. Are you protecting this data from criminals and casual wiretappers? Or are you trying to hide it from government surveillance and intelligence agencies? For the former, an SSL certificate signed and issued by a reputable authority is more than sufficient. For the latter, you have to consider where your certificate is coming from, and who can access the root CA that issued it; it might be better to generate your own, and devise some further scheme on top of SSL.
I've been tasked with development of an intranet interface for command line software, and now I'm researching security options. Our command line application is finished, but I haven't started writing the web interface. I don't know exactly what the security requirements are for potential customers, although I believe ssh is generally acceptable for the command line interface. With this in mind, I'm asking for help developing a menu of choices with their associated pros/cons. Some day, we may consider releasing our web interface to the internet, so I'm willing to consider more security than currently necessary if it's easy and/or free.
I've been doing a lot of reading, and my tentative conclusion is that SSL security with no certificate is the best approach, not because less security is unacceptable, but because SSL is the standard and because it doesn't appear to be difficult to set up. I, a security non-expert, wouldn't need to explain why less security is acceptable to security non-experts. I could upgrade my application to use a certificate in the future if necessary.
Here's a list of SSL related security choices, sorted by my perception of security level with my comments. What level of protection do I need?
No SSL. This might be acceptable if our customers aren't worried about their employees seeing/changing each others' data. Their employees might want to share results with each other anyway, and I could use IP based access control and/or passwords for security.
Do SSL with no certificate. This encrypts the communication, which at least protects the data from being read by unauthorized employees. Using a password, this is the same level of security as ssh on the command line, right? I don't need to worry about man-in-the-middle attacks in an intranet, right? A con for this approach would be if there were loads of browser warning messages.
Do SSL with a self-signed certificate. What does this give me that no certificate gives me? If the DNS can be changed inappropriately, then the customer then my application is the least of their concerns. Worded another way, if the DNS can change, then I think ssh would be vulnerable too.
Do SSL with a local Certificate Authority. OpenSSL lets me make my own Certificate Authority. What does this give me that a self-signed certificate does not? I'm assuming that on a LAN, it's less important for the server to be verified.
Do SSL with an external Certificate Authority. Is there ever a reason to go this route for an intranet? I found some "intranet certificates" for sale online -- but it's not clear what they're offering I can't do myself.
For reference, this page might be useful for comparing certificates:
http://httpd.apache.org/docs/trunk/ssl/ssl_faq.html#aboutcerts
[update]
Here's an article discussing the risks and rules of obtaining an internal certificate from a public CA.
Yes, certificates are still useful for Intranet SSL.
There's an important difference between SSH and SSL-without-a-certificate: when you first connect to a server with SSH, your SSH stores the server's fingerprint. If you then try to connect to what the SSH client believes to be the same machine but gets back a different fingerprint, it alerts you that there might be someone intercepting your communications.
SSL-without-a-certificate, on the other hand, does not store the server's fingerprint. Your communications will still be encrypted, but if someone somehow hijacks the DNS server as you mentioned, or, as Rushyo notes, does ARP poisoning or something similar, they would be able to perform a man-in-the-middle attack. SSH, as previously mentioned, would (supposing you had connected to the correct server some time in the past) notice that the fingerprint had changed and alert you.
A self-signed certificate would be comparable in security to SSH. A man in the middle could generate their own self-signed certificate, but as long as your applications are configured to only accept that self-signed certificate, you should get an alert similar to that that SSH will give you.
A local certificate authority gives you security similar to self-signed certificates, but may be more scalable. Should you have multiple servers, each can have their own certificate, but a client only needs the top-level one to trust all of them. If a server is compromised, you can revoke its certificate rather than having to change every server's certificate.
I don't believe an external certificate authority has any advantages, other than possibly less configuration if your machines already have the certificate authority trusted.
Lastly, I don't know enough about two-factor authentication to evaluate it, but for most applications, SSL should be sufficient.
Disclaimer: I am not a security expert.
Do SSL with an external Certificate Authority. Is there ever a reason to go this route for an intranet? I found some "intranet certificates" for sale online -- but it's not clear what they're offering I can't do myself.
The benefit is that you don't need to learn how to setup your own Certificate Authority if you need to manage a decent number of certificates and/or machines. Such a certificate would already be trusted by all browsers without you needing to install your own certificates into the trusted store.
However, this is actually less secure because somebody could purchase a certificate for a different intranet and use it on your network. For this reason, SSL vendors no longer offer this service. For more information, see: https://www.godaddy.com/help/phasing-out-intranet-names-and-ip-addresses-in-ssls-6935
If you only have a very small intranet, then I would recommend using a self-signed certificate, and then just add each self-signed certificate to each computer's trusted store.
However, it quickly becomes impractical to install a new certificate on every computer in your intranet whenever you want to add a new computer. At this point, you want to setup your own Certificate Authority so that you only need to install a single CA certificate in each computer's trusted store.
In J2ME when you sign a JAR with a certificate chain that includes an intermediate certificate (such as one from obtained from Verisign), does the device need to have the intermediate certificate installed as well as the root certificate during verification?
I am guessing the answer is no because the intermediate certificates are stored in the JAD file in the MIDlet-n-m properties where m is 2 or greater, and I believe the device references these while verifying. If that is true then J2ME certificates are different from SSL website certificates which require the intermediate certificates be installed in the browser, correct?
Finally if this is all true then couldn't anyone who gets a certificate from Verisign or any other CA with their root certificate on the device just go ahead and sign their friend's certificates and then their friends will be trusted?
Seems like a flaw in the system if this is all true...
The certificate one gets from verisign would typically be trusted to sign a MIDlet but not another certificate. Certificates trusted to sign MIDlets usually are not trusted to sign native applications either.
Between this and the (admitedly advanced and not always available) ability to revoke certificates, the system is fairly safe as long as trust is preceded by due diligence (so your Mobile Network Operator doesn't start trusting trojans and such...)
Frankly, it's not like mobile airwaves are inherently secure anyway.
Whenever I see it being talked about, it sounds like one simply 'turns on' SSL and then all requests/responses to/from an online server are magically secure.
Is that right? Is SSL just about code - can I write two apps and make them communicate via SSL, or do you have to somehow register/certificate them externally?
Secure web pages are requested on port 443 instead of the normal port 80. The SSL protocol (plenty complicated in and of itself) is responsible for securing communication, and using the certificate information on both the SERVER and the BROWSER to authenticate the server as being who they say they are.
Generating an SSL certificate is easy. Generating one that is based on the information embedded in 99% of web browsers costs money. But the technical aspects are not different.
You see, there are organizations (Verisign, Globalsign, etc...) that have had their certificate authority information INCLUDED with browsers for many years. That way, when you visit a site that has a certificate that they produced (signed), your browser says:
"well, if Verisign trusts XYZ.com, and I trust Verisign, then I trust XYZ.com"
The process is easy:
Go to a competent SSL vendor, such as GlobalSign. Create a KEY and Certificate Request on the webserver. Use them (and your credit card) to buy a certificate. Install it on the server. Point the web-browser to HTTPS (port 443). The rest is done for you.
SSL is a protocol for encrypted communications over a TCP connection (or some other reliable scheme). The encryption uses public key encryption using X.509 certificates. SSL handles both privacy and trust. These are related: if you don't trust the server, you don't believe that the server hasn't handed out its private key to everyone in North America.
Thus, the client has to trust the server's certificate. For public sites, this is arranged via a hierarchy of certificate authorities, with the root authorities trusted, automatically, by browsers and things like the JRE's socket implementation.
Anyone can generate a self-signed certificate for a server, but then the client has to be manually configured to trust it.
SSL is not, in itself, a magic bullet that makes everything secure. Security has no such things.
SSL is, however, an already-designed, ready-to-use system for solving a common problem: secure stream communication over a network connection.
There are two things you need to do to secure your application with SSL:
Modify the application's code to use SSL.
Determine the certificate trust model (and deploy and configure the application respectively).
Other answers and documentation provide better answers to how to do each of these things than I could provide.
I'll throw caution to the wind and attempt to condense an enormous subject.
SSL attempts to solve two problems:
1) Authentication and hence trust i.e can the client trust the server and vice versa
2) Communication without eavesdropping
1) Is handled by means of an intermediary i.e a trusted 3rd party - these are called 'Root Certificate Authorities' ( or Root CAs ) examples include Verisign, RSA etc
If a company wants to authenticate users and more importantly if a user wants to authenticate the company's website it's connecting to i.e your bank then the Root CA issues the company a certificate which effectively says 'I the trusted Root CA verify that I trust that Company X are who they say they are and am issuing a certificate accordingly'. So you get a chain of trust i.e I trust the certificate from ACME Co because Root CA Verisign created and issued it.
2) Once the two parties have authenticated then the certificate ( typically X590 ) is used to form a secure connection using public/private key encryption.
Hopelessly simple and incomplete but hope that gives a rough idea
Yes and no. You should self-sign a certificate and test the site with SSL internally before deploying it with SSL, first of all. To make the public site secure under SSL, you will need to purchase a certificate from one of any number of certificate providers. Then you will have a certificate signed by a trusted third party, tied to your domain name, so that users' browsers won't complain that the certificate is invalid, etc. Turning SSL on is pretty much just flipping a switch, otherwise.
For the most part you need to buy and register a certificate externally.
You need to have your server certificate signed by a Certificate Authority (CA), for which they will charge you. The client needs to trust that CA and have a copy of the relevant CA public key. The client can then check that you are who you claim to be (including domain name (from DNS) and display name for https).
This is a good tutorial on how to create self signed certificates for Apache.
If you want to know how SSL works on either the Server or the Client, then I suggest Googling it. As you suspected, it is a ridiculesly complex procedure, with lots of communication between the client and server, a lot of very peculiar math, and tons of processing. There is also a lot of theory involved, several protocols and many different algorithms and encryption standards. It's quite incredible how changing http:// to https:// is so simple to the user, but results in so much work for both sides, and is so secure. To really understand it you need to take a security course (multiple courses to fully understand it), as the entire history of encryption goes into making your login to Gmail secure.
Turning on TLS (colloquially "SSL") does not make your site magically secure. You may still be vulnerable to application-level vulnerabilities like stack overflows, SQL injection, XSS, and CSRF.
As other answers have explained, TLS only protects against a man in the middle. Traffic between a client and a properly-configured TLS server cannot be intercepted or modified, and the client can reliably confirm the identity of the server by validating the X.509 certificate. This prevents an attacker from impersonating your TLS server.
SSL actually does two things:
Encrypts the communication so that an observer seeing the data stream will not be able to read the conversation.
Guarantees that you are talking to who you think you are talking to.
It is only for #2 that you need to get official certificates. If you only care to encrypt the communication without setting up a trust relationship, you can use self-signed certificates or you can use an algorithm that does not require certificates (i.e. Diffie-Hellman).
I'm currently working on a project where I've created a CA cert and a couple of child certs to that CA cert. The certificates are going to be used to protect inter-server communication in a SAMLV2 setup so I'm going to have a cert for the identity provider and a cert for the service provider. The user/browser isn't going to validate the certs so it's only the servers that need to trust my custom CA. My cert tree looks something like this:
CustomRootCACert
CustomIdentityProviderCert
CustomServiceProviderCert
Now, I've heard a lot of people saying it's bad to use a home-made certificate in production. But when I ask why, people usually just mutters something about security but never go into the details. Are there any technical reasons not to use my own certs in production? I can't think of any... Of course I realize that if I lose control of my root cert anyone could start creating all sorts of certificates. But in this case they would also have to install the certificates on my servers and configure the saml application to use them. Only then could they start to generate fake saml requests and responses to my applications.
If this is the only problem, this solution (using home-made certs in production) would still be better than the login setup we have today.
Ask yourself what a certificate proves.
If you get a certificate issued by a reputable CA, then it proves that the certificate holder has verified their identity to that CA, to their standards of proof.
If you get a certificate issued by an ad-hoc CA, then it proves that someone knows how to make certificates.
If you control both ends of the conversation, I think it's fine to have your own private CA for the purpose. You would trust your own CA. You can probably make this very secure indeed (by keeping the CA private key in a safe place offline, and making signing a sneakernet exercise).
The difficulty would be if you needed to persuade anyone else to trust your CA. Why should they? You would need to convince them that it was safe to do so, and they would have the admin overhead of adding your CA certificate to their clients.
Since you are only using the certificate to protect the network traffic and not authenticate users/computers then it sounds like you have a legitimate use for using MakeCert.exe.
I feel there is one thing worth mentioning. After you spend some time working with the MakeCert.exe interface you might to consider using a Stand-Alone Root Certificate Server instead.
Consider these points:
(Almost) All versions of Windows Server include Certificate Server Services for free
Windows Stand-Alone CA Server is extremely simple to install and configure
Windows Stand-Alone CA Server can be installed on a Virtual Machine and turned on/off whenever you need to issue an additional certificate
A VM based Windows Stand-Alone CA Server can be run using very little memory (ex. 256mb)
Windows Stand-Alone CA Server includes a nice and clean web based enrollment interface to simplify requesting certificates.
CRL checking can be used or not used, depending on your needs.
In the past I first started with selfssl.exe and eventually moved to MakeCert.exe to generate a root certificate and then issued my client certificates. But after struggling with the syntax and always having to remember where I put that Root Certificate I switched over to using a Stand-Alone Root CA in a virtual machine.
IF the certificates are only passed around internally, between your own servers (and not used by the client, one way or the other) - then it is perfectly acceptable to use your own internal CA.
HOWEVER, one suggestion - dont have your Root CA issue your provider certs. Instead, use your Root CA to create an Intermediate CA - then use that to issue provider certificates. This will help you longer term, when you have to start managing certificate expiration, extending the system/infrastructure, revocation lists, etc.
There is no real issue with using a self signed certificate in private use, that is use when you control all of the systems that need to trust the homebrew root certificate.
You manually install your root cert onto each of the systems that need to trust it.
You can do this in production as well for browser use - for example within an organisation where the root ca can be rolled out via software distrubution method - there is no reason to go to the expense of paying a Certificate Authority that Microsoft happens to trust.
[edit]
In terms of secruity the issue is one of containing the private key for your root certificate, as long as you can ensure that stays private then you can validate any certificate off that root.