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.
Related
I have an embedded device which runs a web server.I need to integrate the server SSL certificate for the web server. If I have multiple such boxes, is it required to have different SSL for each box?
You can buy a wildcard certificate say for *.mydevices.mydomain.com, then give each device a name like myRouter1.mydevices.mydomain.com and that's it. Certificate Authorities do sell wildcard certificates, yet they are more expensive (but if you have many devices, this will be cheaper).
You need to consider one thing though - if the certificate's private key leaks from the device in any way (eg. the device is stolen altogether), you can revoke the certificate. But if you have one certificate shared on all devices, then the leak will invalidate all devices at the same time and you will have to replace the no more valid certificate on all devices.
Of course, you're going to get an "it depends":
If your users require a CA-signed certificate, then you'll have to pay for one for each box and load it some way. Browser's then won't complain...
If your users will allow a self-signed certificate, then you can just have the box generate one when it is commissioned. But, your user's browser's will complain...
If you ship with the same certificate, then it's kind of a security problem for you.
I would build a mechanism in so the user can load a certificate to the box in the field. Then you can satisfy whatever need comes up.
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.
This is just a general question regarding the debate between self-signed certificates and CA certificates...
I understand the benefits for a CA certificate due to the avoided warnings generated in most browsers, but how does a CA certificate benefit actual security? I commonly hear the biggest threat is man-in-the-middle attacks, and while I understand this threat using a self-signed certificate, I don't understand how a CA certificate prevents this. I know CAs perform their own security algorithms couldn't the same algorithms be used on self-signed certificates?
I guess I'm just a little irritated by the big business revolving around the need for CA certificates but can't seem to find anything different about them other then these supposed additional security checks they perform. Is there anything a CA can provide from a security point-of-view that self-signed certificates cannot?
Spoofing. If the other party fakes a self-signed certificate, you have no way to check this. In order to check that you have received the valid certificate and not a forged one, you need third-party check which can not be easily spoofed. This is done by carrying the list of root CA certificates (and some intermediate certificates) with your client-side software (Windows includes such certificates for you and major browsers do the same) and verifying the certificate you receive from the server using those CA certificates. With self-signed certificates such verification is not possible.
Of course, you can carry the self-signed certificate with your client application (and this is what some developers do, especially for in-house applications) but this doesn't work with browsers.
The difference isn't in the algorithm, it's in whether people trust the certificate authority or not.
The point of a certificate is to verify that you are making the connection with whoever it is that you intend to make the connection with.
If I say to you "I'm the right server, trust me on this", you may choose not to believe me (after all, you don't know me).
If I say to you "I'm the right server, and I have a certificate to prove it", you could say "ok, and who gave you this certificate?" If my reply is "Joe from around the corner", you may still choose not to believe me.
But if I say "I have a certificate, and you can confirm it with a third party that you trust", you may decide that this is a good proof of identity.
How you confirm it is what the standard is all about (e.g. as described in RFC 5280). But that's just technicalities. You could use the exact same algorithm for a certificate that originated from VeriSign and for a certificate you generate yourself.
The real question is about trust: do you trust whoever is giving you the "proof of identity". We trust VeriSign enough to allow any proof of identity from them to be accepted by every browser. Should we trust individuals that generate their own self-signed certificates? We might do in some cases (in which case you can install their certificates in your browser manually), but not as a general rule.
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.