Let's say I sign a SSL certificate for myself, and I'm not using a certified CA. What are the risks and/or threats of doing it?
asked Oct 13, 2011 at 18:06
-
1In short: There's no real threat/risks to you, but your clients who use whatever services are signed by the cert will probably be dubious of its validity.– IsziCommented Oct 13, 2011 at 18:54
-
Side note: why not use certified CA? if cost is the reason, there are free lvl 1 certs. better then self signed.– Mark CokerCommented Sep 9, 2015 at 1:01
Add a comment
|
2 Answers
The risks are for the client. The point of the SSL server certificate is that it is used by the client to know the server public key, with some level of guarantee that the key indeed belongs to the intended server. The guarantee comes from the CA: the CA is supposed to perform extensive verification of the requester identity before issuing the certificate.
When a client (the user and his Web browser) "accepts" a certificate which has not been issued by one of the CA that the client trusts (the CA which were embedded in Windows by Microsoft), then the risk is that the client is currently talking to a fake server, i.e. is under attack. Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.
On a general basis, you do not want to train your users to ignore the scary security warning from the browser, because this makes them vulnerable to such server impersonation attacks (which are not that hard to mount, e.g. with DNS poisoning). On the other hand, if you can confirm, through some other way, that the certificate is genuine that one time, then the browser will remember the certificate and will not show warnings for subsequent visits as long as the same self-signed certificate is used. The newly proposed Convergence PKI is an extension of this principle. Note that this "remembered certificate" holds as long as the certificate is unchanged, so you really want to set the expiry date of your self-signed certificate in the far future (but not beyond 2038 if you want to avoid interoperability issues).
It shall be noted that since a self-signed certificate is not "managed" by a CA, there is no possible revocation. If an attacker steals your private key, you permanently lose, whereas CA-issued certificates still have the theoretical safety net of revocation (a way for the CA to declare that a given certificate is rotten). In practice, current Web browser do not check revocation status anyway.
answered Oct 13, 2011 at 18:35
-
11"extensive verification" ... that or mere domain validation .... Commented Oct 14, 2011 at 1:42
From the accepted answer:
Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.
Not true.
Because the Internet works by passing data from router to router until your data gets to it's destination. Every router in between is an opportunity for malicious code on that router to re-write your packet, and you'd never know the difference, unless you have some way to verify that the packet is from the trusted server.
A crypto key, if you have the correct key, can verify for you that the data hasn't been tampered with. The problem is, however, that before you can begin encrypted communications, you must do an unencrypted key exchange, where the server gives you it's crypto key. Here's where the man-in-the-middle has an opportunity. If your traffic is going through my router, I can intercept the self-signed key from the server, and generate a new self-signed key with the same server name, etc in it, so that it looks like the self-signed key from your server, but which allows me to decrypt the communications between you and the server. My router then establishes a connection to the server using the correct key, and as data passes between you and the server, I unencrypt the data using the real key, then re-encrypt it using the 'fake' key. So, the data is encrypted between me and the server, and between me and you, but gets unencrypted in my router, giving me the opportunity to spy on your data, or even alter if if I want.
So basically...using a self signed certificate is completely unsafe unless
- you control every machine between you and the server
- OR you check that the keys in the certificate are what you expect them to be.
-
4It is nice of you to explain the scenario of a MITM scenario for SSL in simple terms, but the accepted answer does not contradict anything of what you said. A man in the middle who intercepts certificates and keeps two differently encrypted connections is certainly not a passive attacker. Commented Sep 8, 2015 at 23:57
-
@zinfandel passive attack as defined by the answer
the attacker observes the data but does not alter it in any wayis not thwarted.– basaratCommented Sep 9, 2015 at 0:37 -
2@basarat - I think you misunderstood what the statement you quoted is saying. The statement basically says, "If you don't know the key, unless you perform a MITM attack, you cannot read data sent over SSL." In other words, the data being observed by the passive attacker is gibberish and useless. That is certainly true, and it is why a self-signed cert is much better than nothing if you need to secure data being transferred. Thus self-signed cannot be described as "completely unsafe".– TTTCommented Dec 4, 2015 at 18:02
-
@basarat are you sure that server sends the session key to the client? I was under the impression that both parties securely generate the session key based on random nonces that they send each other.– ArelCommented Jun 3, 2019 at 23:17