"Secure Connection Failed" problem

[jasonb]

Please get rid of the idea that an IP address gives you any guarantees of any kind

Please re-read what I wrote: "If I have two computers sitting in a lab, not connected to the Internet, and I'm sending from one to the other - I know for a certainly what the receiving machine is and what the sender is." Tell me how, in that case, having a signed certificate offers any benefit to me - or that the IP addresses, in that case, don't tell me something about the sender and the receiver? And, before you say that that has nothing to do with reality, I'm trying to get you away from 100% absolutes where "always" and "never" are thrown around and there isn't room for discussion of all possibilities.

Conclusion: An IP address is 100% useless for authentication!

That's too extreme of a statement - because you aren't qualifying yourself. In some contexts, it's quite correct; in others, it's wrong. I would say that an IP address is 70% useful for authentication. (With the remaining bits negated by security holes and infrastructure.) That's just where I rate it without really analysing everything. I'm sure that number will vary based on the subjective position of each person. You're trying to set up an hermetic environment where if there is any chance of a security breach then it should be considered useless and unusable. That's a self-defeating position because no such condition exists, nor do I believe it will ever exist. For any lock made, there will always be somebody who comes up with a way to get around it.

Instead, you have to assign variables of risk to everything you do, calculate your current situation, then ask yourself if things are secure enough for you or not.

It's worse in the sense that it pretends a "security" to the user that doesn't exist!

You're beating a dead horse here. LOL I've already acknowledged this point. Shouting about it again isn't going strengthen your argument in any way. As I've already responded, if the sender is aware of the insecurity of the receiver, then they still have to do (or not do) something from there.

You are not forced to do anything.

Okay, maybe not "forced". But some action (or inaction) needs to be taken on your part about the situation.

If you understand what an invalid certificate means (that means you are aware that the connection will not be "secure" in fact) then you can add the "invalid" certificate to your Exception list and proceed. SeaMonkey doesn't prevent you from doing that!

Quite. That's exactly what we're saying. Given the fact that we are going to proceed - it's surely better to proceed with an encrypted connection (to prevent additional risks) than a non-encrypted connection. An encrypted connection isn't just about the verifiability of the receiver. It offers additional benefits too.

Also encryption takes additional CPU overhead

Well, that's just another factor in your decision to encrypt or not.

But it shouldn't be automatic for the reasons explained enough. Also it shouldn't be reachable too easy, because that would encourage the users to take a security risks they don't even understand. People just shouldn't accept invalid certificated, unless they know exactly what that means..."

Oh, I totally agree.

Which makes me wonder why this whole discussion got started in the first place. Rather than trying to argue johndoe32102002 out of using encryption at all, surely it could have just been explained to him that all he needs to do is add an exception? I see that you mentioned it at the end of your original reply to him - but maybe he didn't know how to actually do that, and the heated opposition to doing so de-railed things.

johndoe32102002, here's what you need to do to be able to access a site that SeaMonkey is blocking (I'm not sure how Firefox works, but I expect that it's similar):

1. You'll get a Web page that says you're blocked.
2. Click the "Add Exception..." button. (Depending on the specific build of SeaMonkey nightly that you're running, you may need to first click on the text "I Understand the Risks" in order to get this button to appear.)
3. A new window will pop up. Click on the "Get Certificate" button.
4. You can view the certificate if you wish by clicking the "View" button.
5. If you want to always get access to this specific site, just click the "Confirm Security Exception" button.
6. If you only want to get access to it this one time, first uncheck "Permanently store this exception" and then click on the "Confirm Security Exception" button.

If you find that this doesn't work for you, please report back. (And my apologies for not addressing your question here first.)

[jasonb]

Also I still can't get SeaMonkey to get email's via secure SSL connection from university mail server.
It always throws a "sec_error_unkown_issuer" message, no matter how often I try to import the certificate and add an exception.
Seems like adding an exception for "invalid" certificates doesn't work for the mail client.

BTW: Did you figure this out? (Or do you think, now, that you shouldn't be reading your university mail because it's not actually secure. <grin> Sorry, I couldn't resist.)

[LoRd_MuldeR]

Please get rid of the idea that an IP address gives you any guarantees of any kind

Please re-read what I wrote: "If I have two computers sitting in a lab, not connected to the Internet, and I'm sending from one to the other - I know for a certainly what the receiving machine is and what the sender is." Tell me how, in that case, having a signed certificate offers any benefit to me - or that the IP addresses, in that case, don't tell me something about the sender and the receiver? And, before you say that that has nothing to do with reality, I'm trying to get you away from 100% absolutes where "always" and "never" are thrown around and there isn't room for discussion of all possibilities.

Then you didn't need a "secure" connection from the very beginning

Conclusion: An IP address is 100% useless for authentication!

That's too extreme of a statement - because you aren't qualifying yourself. In some contexts, it's quite correct; in others, it's wrong. I would say that an IP address is 70% useful for authentication. (With the remaining bits negated by security holes and infrastructure.) That's just where I rate it without really analysing everything. I'm sure that number will vary based on the subjective position of each person. You're trying to set up an hermetic environment where if there is any chance of a security breach then it should be considered useless and unusable. That's a self-defeating position because no such condition exists, nor do I believe it will ever exist. For any lock made, there will always be somebody who comes up with a way to get around it.

Instead, you have to assign variables of risk to everything you do, calculate your current situation, then ask yourself if things are secure enough for you or not.

An IP address is 100% useless for authentication from a cryptographic point of view (the only point of view that makes sense here), for the reasons I already explained.
For other purposes than cryptography you may use the IP address for identifying people indeed (just think of web-server statistics), but that is irrelevant here.

If you don't understand this, you probably were never sitting in a cryptography lecture...

You are not forced to do anything.

Okay, maybe not "forced". But some action (or inaction) needs to be taken on your part about the situation.

I'm really relieved that it is implemented that way. Anything else would be a cryptographic nightmare

If you understand what an invalid certificate means (that means you are aware that the connection will not be "secure" in fact) then you can add the "invalid" certificate to your Exception list and proceed. SeaMonkey doesn't prevent you from doing that!

Given the fact that we are going to proceed - it's surely better to proceed with an encrypted connection (to prevent additional risks) than a non-encrypted connection.

What? No it isn't

It is a trade-off and you must decide very very carefully!

The decision is not using an encrypted connection or an unencrypted connection. If you think this is the decision, then you miss the most important point.
Of course we don't want anybody except the receiver to be able to read our data (encryption), but first of all we want to know to whom we are talking to (authentication).

The decision is:
Do I trust that sever although it doesn't have a valid certificate and quite possibly may NOT be the server it pretends to be ???

And if you decide to NOT trust the server, then you simply move along an do NOT give any information to that server at all! Through NONE kind of connection

Also I still can't get SeaMonkey to get email's via secure SSL connection from university mail server.
It always throws a "sec_error_unkown_issuer" message, no matter how often I try to import the certificate and add an exception.
Seems like adding an exception for "invalid" certificates doesn't work for the mail client.

BTW: Did you figure this out? (Or do you think, now, that you shouldn't be reading your university mail because it's not actually secure. <grin> Sorry, I couldn't resist.)

Now that this feature of SeaMonkey is working as it should, I was able to import the valid(!) certificate of my university and can now flawlessly access the server.

Note that I did not put the certificate in question the my Exception list.
Instead I imported the missing Root certificate and know the certificate in question can successfully be recognized as being valid (which it couldn't before).

And now I can be sure that I'm sending my login data (username + PW) to the university's mail server and not to someone else

[BenoitRen]

LoRd_MuldeR, I did not say "I don't know enough about the certificate authorities to actually comment"; jasonb did.

Also that feature of SeaMonkey shouldn't be reachable too easy, because that would encourage the users to take security risks they don't even understand. People just shouldn't accept invalid certificated, unless they know exactly what that means.

This is SeaMonkey, which is geared at power users.