"Secure Connection Failed" problem

Discussion about Seamonkey builds
johndoe32102002
Posts: 7
Joined: October 21st, 2007, 2:35 am

Post by johndoe32102002 »

FIREFOX DEVELOPERS -- THIS IS A BUG! PLEASE FIX IT!

I can not get to the following website, https://search.auburn.edu, because Firefox chooses to BLOCK and CENSOR websites based on the security of their SSL certificate. Please fix this in the next Firefox version.
johndoe32102002
Posts: 7
Joined: October 21st, 2007, 2:35 am

Post by johndoe32102002 »

User avatar
Andy Boze
Posts: 2755
Joined: June 30th, 2005, 9:53 pm
Location: South Bend, IN

Post by Andy Boze »

Since this is a support forum for SeaMonkey, I can't tell you exactly what to do with Firefox. The certificate expired in 2001 for https://search.auburn.edu/ . You can add an exception for it in your certificates manager. If I were you, though, I'd contact the folks at Auburn's OIT, http://www.auburn.edu/oit/ , to find out if that server is still meant to be used. Maybe you should be using this instead, http://www.auburn.edu/main/ldap.html . Just a thought.
But then again, I may be wrong.
johndoe32102002
Posts: 7
Joined: October 21st, 2007, 2:35 am

Re: "Secure Connection Failed" problem

Post by johndoe32102002 »

Seamonkey and Firefox still block HTTPS/SSL pages with invalid certificates -- Just try to access your 2Wire router: https://192.168.1.1 or https://192.168.1.100 to find out you cannot!
User avatar
LoRd_MuldeR
Posts: 204
Joined: January 21st, 2007, 2:26 pm

Re: "Secure Connection Failed" problem

Post by LoRd_MuldeR »

johndoe32102002 wrote:Seamonkey and Firefox still block HTTPS/SSL pages with invalid certificates -- Just try to access your 2Wire router: https://192.168.1.1 or https://192.168.1.100 to find out you cannot!


That's because a "secure" connection is absolutely useless without a valid certificate!

If you can't ensure that the person/computer one the other side really is the person/computer it pretends to be, you don't need to encrypt your data.
The person/computer you are connected to through the secure connection might very well be the attacker!

So the only sane thing you can do as a web-browser is preventing any "secure" connection, unless the target host can identify itself with a valid certificate.
A simple message box with an "ignore" button is insufficient, as the normal user wouldn't understand what an invalid certificate actually means.
The user probably would choose "ignore" overhasty, which leads to really dangerous security problems!

Advanced users who know what they are doing are still able to put "invalid" certificates to their "Exceptions" list. Where is the problem?
The only reason I opened this Thread was that the "Add Exception" option was still missing at that time...
User avatar
BenoitRen
Posts: 5946
Joined: April 11th, 2004, 10:20 am
Location: Belgium

Re: "Secure Connection Failed" problem

Post by BenoitRen »

Sending unencrypted login data to a site you trust is better than sending encrypted login data to a site that I trust with a self-signed certificate?
User avatar
LoRd_MuldeR
Posts: 204
Joined: January 21st, 2007, 2:26 pm

Re: "Secure Connection Failed" problem

Post by LoRd_MuldeR »

BenoitRen wrote:Sending unencrypted login data to a site you trust is better than sending encrypted login data to a site that I trust with a self-signed certificate?


Sending your login data (or whatever data) through an encrypted connection is as insecure as not encrypting your data at all, unless you can identify the person/machine on the other side of the "secure" connection. And that's exactly what a certificate is good for. An attacker can very well pretend to be a "secure" host! You have no way to check the authenticity of your communication partner, except for checking his certificate. If you don't do that, you might be establishing the encrypted connection directly to the attacker's machine and you won't even notice. However if you know what you are doing and if you are aware of all the risks, then you can still add the invalid (or "self-signed") certificate to your "Exception" list - at any time. But a browser really shouldn't pretend a "secure" connection to the user when it's not secure at all in fact...
User avatar
BenoitRen
Posts: 5946
Joined: April 11th, 2004, 10:20 am
Location: Belgium

Re: "Secure Connection Failed" problem

Post by BenoitRen »

If I'm sending data to a site through a non-secure connection, people that get a hold of the data in the middle can read it. If the connection is secure, they can't. So again, how is a secure connection with self-signed certificate, less safe than no secure connection at all?
User avatar
Philip Chee
Posts: 6475
Joined: March 1st, 2005, 3:03 pm
Contact:

Re: "Secure Connection Failed" problem

Post by Philip Chee »

BenoitRen wrote:If I'm sending data to a site through a non-secure connection, people that get a hold of the data in the middle can read it. If the connection is secure, they can't. So again, how is a secure connection with self-signed certificate, less safe than no secure connection at all?

It gives the user a false sense of security, and they might send sensitive information over such a link that they might otherwise not have.

Phil
User avatar
jasonb
Moderator
Posts: 1104
Joined: October 18th, 2007, 1:52 pm

Re: "Secure Connection Failed" problem

Post by jasonb »

Sending your login data (or whatever data) through an encrypted connection is as insecure as not encrypting your data at all

I disagree. That's only true if the trust of the receiver is in question. Sending encrypted is still better than unencrypted if you want to prevent anybody between you and the receiver from sniffing your data...
(I actually joined in 2002 and made 6,093 posts, now shown under "old jasonb", before the site tried to kill me off...)
User avatar
LoRd_MuldeR
Posts: 204
Joined: January 21st, 2007, 2:26 pm

Re: "Secure Connection Failed" problem

Post by LoRd_MuldeR »

jasonb wrote:
Sending your login data (or whatever data) through an encrypted connection is as insecure as not encrypting your data at all

I disagree. That's only true if the trust of the receiver is in question.


And the trust of the receiver always is in question, unless it provides a valid certificate (signed by an authority you trust).


jasonb wrote:Sending encrypted is still better than unencrypted if you want to prevent anybody between you and the receiver from sniffing your data...


Wrong. Unless you verify the authenticity of the receiver with a valid certificate, "anybody between you and the receiver" can pretend to be the receiver.
So possibly you'd establish the "secure" connection right to the attackers machine. That's called a "man in the middle" attack.


BenoitRen wrote:If I'm sending data to a site through a non-secure connection, people that get a hold of the data in the middle can read it.


Again wrong. And again the "man in the middle" attack is the problem.
People in the middle can pretend to be the receiver and you can NOT verify their identity without a valid certificate (signed by an authority you trust).

So you may agree on a "secret" key with somebody you think is the receiver, but who is the attacker in fact.
In the next step the attacker pretends to be you an establishes an encrypted connection to the actual receiver. Whoops, attack applied successfully!
The connection is still encrypted (feels like "secure"), but isn't secure at all, because the attacker knows the secret key(s) and can read everything.

Please get rid of the naive idea that "encrypted" equals "secure", which definitely is wrong in reality...

In short: No valid certificate -> No authentication of the communication partner possible -> No secure connection


Philip Chee wrote:It gives the user a false sense of security, and they might send sensitive information over such a link that they might otherwise not have.


Very right! :)



That info is from Wikipedia:

SSL ist ohne eine zertifikatsbasierte Authentifizierung problematisch, wenn ein Man-In-The-Middle-Angriff erfolgt: Ist der Man-In-The-Middle vor der Übergabe des Schlüssels aktiv, kann er mit beiden Seiten den Schlüssel tauschen und so den gesamten Datenverkehr im Klartext mitschneiden.


It's from the German article, but maybe you can understand it anyway or translate it ;)

In basically says that SSL does NOT work without certificate-based authentication, because of the Man-In-The-Middle attack problem...
User avatar
BenoitRen
Posts: 5946
Joined: April 11th, 2004, 10:20 am
Location: Belgium

Re: "Secure Connection Failed" problem

Post by BenoitRen »

Wait, you're saying that if I transmit data over a non-secure connection, and someone in the middle gets a hold of it, (s)he can't read it?

By the way, I don't necessarily trust the authorities, like VeriSign. They don't do enough checking.
User avatar
jasonb
Moderator
Posts: 1104
Joined: October 18th, 2007, 1:52 pm

Re: "Secure Connection Failed" problem

Post by jasonb »

LoRd_MuldeR wrote:And the trust of the receiver always is in question, unless it provides a valid certificate (signed by an authority you trust).

I'll disagree with this too - as an absolute statement of fact. 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 certainty what the receiving machine is and what the sender is. There are other situations too. I could be sending to a buddy of mine half-way around the world. We're on the phone, and I've been told what that computer's IP address is. I may not be absolutely, completely certain that when I go to that IP I'm actually hitting the machine I've been told about, but for all intents and purposes I am. Any other edge case - where somebody knows to, and wants to, redirect me somewhere else - is the height of paranoia, especially if his computer isn't anything important, and one that's just been set up. (It's quite improbable that anybody would bother with a man in the middle for something like that.) That may be fine to consider when security is vitally important - but not for everyday life.

LoRd_MuldeR wrote:Wrong. Unless you verify the authenticity of the receiver with a valid certificate, "anybody between you and the receiver" can pretend to be the receiver.
So possibly you'd establish the "secure" connection right to the attackers machine. That's called a "man in the middle" attack.

I do know what the term is. <grin> You may be able to argue that an encrypted connection is no better than a non-encrypted connection in some cases (and not all of them) - but you certainly can't argue that it's any worse. Assuming, that is, that the sender takes on the responsibility and knowledge for things that "might" be happening at the receiving end - so that there are no false senses of security.

BenotRen wrote:Wait, you're saying that if I transmit data over a non-secure connection, and someone in the middle gets a hold of it, (s)he can't read it?

No, they're not saying that. If you transmit data over a non-secure connection, and somebody gets hold of it, it will be in plain text and quite readable. If you transmit over a secure connection, you negate any possibility of that happening. This is what makes the argument that, everything being equal, a non-secure connection is no worse than a secure connection somewhat misleading.

Let's say that I know that the receiver has an invalid certificate. I have two choices. Either do nothing at all, or accept the risk. If I accept the risk, I would rather also transmit via encryption. If I don't then I needlessly accept the additional risk of the non-verifiable receiver as well as somebody else sniffing things. Why should I be forced to accept both risks when I only need to accept one? If we assign values of risk here, and give both man in the middle and sniffing equal weight (x), I'd rather assume a risk of x than a risk of 2x. (Assuming that I choose to go ahead with a transaction in the first place.)

The problem with this discussion is that one side is talking about theoretical security (which I also agree with, just not in the context of my particular argument), the other is talking about practical security once you hit a site without the proper certificate - and then decide what's better to do at that point (which I'm arguing for). I think that any dissension here is simply because we're arguing about different things. (At least I'm hoping that we are.) What should really be discussed is - what happens with SeaMonkey. I.e. What should it allow the user to do when it hits a site with an invalid certificate. There are really only a few choices: Always allow it, always disallow it, or ask the user what to do in some way (ask each time, remembered site preferences, remember global preferences, etc.).

BenoitRen wrote:By the way, I don't necessarily trust the authorities, like VeriSign. They don't do enough checking.

Do you keep all of your money in a sock buried in the woods somewhere? LOL (Sorry, I couldn't resist. The image just popped into my head.) On a more serious note, nothing is absolutely secure. (I don't know enough about the certificate authorities to actually comment.)
(I actually joined in 2002 and made 6,093 posts, now shown under "old jasonb", before the site tried to kill me off...)
User avatar
LoRd_MuldeR
Posts: 204
Joined: January 21st, 2007, 2:26 pm

Re: "Secure Connection Failed" problem

Post by LoRd_MuldeR »

jasonb wrote:
LoRd_MuldeR wrote:And the trust of the receiver always is in question, unless it provides a valid certificate (signed by an authority you trust).

I'll disagree with this too - as an absolute statement of fact. 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. There are other situations too. I could be sending to a buddy of mine half-way around the world. We're on the phone, and I've been told what that computer's IP address is. I may not be absolutely, completely certain that when I go to that IP I'm actually hitting the machine I've been told about, but for all intents and purposes I am. Any other edge case - where somebody knows to, and wants to, redirect me somewhere else is the height of paranoia - especially if his computer isn't anything important, and one that's just been set up. (It's quite improbably that anybody would bother with a man in the middle on something like that). That may be fine to consider when security is vitally important - but not for everyday life.


Never heard of IP Spoofing, eh?

Please get rid of the idea that the IP protocol gives you any (security) guarantees of any kind [-o<

Any machine on the way that your IP packets travel can pretend to be the target machine easily.
Even machines that your packets wouldn't pass normally can spoof the target IP address and then redirect your IP packets to their own address.
Also note that thanks to Network Address Translation (NAT) there even is no "one machine - one IP address" relation any more!
And no, even in your local lab (not connected to the internet) an attacker may sit on the neighboring table and spoof the IP of your target computer...

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


jasonb wrote:You may be able to argue that an encrypted connection is no better than a non-encrypted connection in some practical cases (or all purely theoretical cases) - but you certainly can't argue that it's any worse.


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

Also encryption takes additional CPU overhead, which is a complete waste, if you did not do the initial handshake properly (which includes a valid certificate), as you'll get encryption but no true security from it!


jasonb wrote:Let's say that I know that the receiver has an invalid certificate. I have two choices. Either do nothing at all, or accept the risk. If I accept the risk, I would rather also transmit via encryption. If I don't then I needlessly accept the additional risk of the non-verifiable receiver as well as a man in the middle attack. Why should I be forced to accept both risks when I only need to accept one? If we assign values of risk here, and give both man in the middle and sniffing equal weight (x), I'd rather assume a risk of x than a risk of 2x. (Assuming that I choose to go ahead with a transaction in the first place.)


You are not forced to do anything. 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! But that must not happen automatically for the reasons explained enough. 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.

If you understand what it means, then I'm the very last person on earth telling you that you aren't allowed to accept invalid certificates. I do it very often too :D


BenoitRen wrote:Wait, you're saying that if I transmit data over a non-secure connection, and someone in the middle gets a hold of it, (s)he can't read it?


The person in the middle of your none-encrypted connection can read the data just as easily as any Man-In-The-Middle attacker in your wrongly (without valid cert) establish encrypted connection.

Conclusion: Both kinds of connections must be considered none-secure! Only the the encrypted one pretends a kind of security that it doesn't offer in fact...


BenoitRen wrote:By the way, I don't necessarily trust the authorities, like VeriSign. They don't do enough checking.


The trust of public-key infrastructures is another topic :roll:

But fact is that "secure" connections on the internet aren't possible without an public-key infrastructure (unless you meet any internet user in reality and exchange a secret key directly from person to person, which means that you need to exchange n^2 keys, where n = 4.000.000.000 at the moment - good luck ^^)


BenoitRen wrote:I don't know enough about the certificate authorities to actually comment


Then you should read about RSA (or asynchronous encryption in general), about Hash functions (e.g. SHA1) and how digital signatures can be built from that.
Once you got that, you can understand how certificates work in fact. Then finally you can read up on public-key infrastructures...
Last edited by LoRd_MuldeR on January 30th, 2009, 10:07 am, edited 2 times in total.
User avatar
Philip Chee
Posts: 6475
Joined: March 1st, 2005, 3:03 pm
Contact:

Re: "Secure Connection Failed" problem

Post by Philip Chee »

jasonb wrote:Do you keep all of your money in a sock buried in the woods somewhere? LOL (Sorry, I couldn't resist. The image just popped into my head.) On a more serious note, nothing is absolutely secure. (I don't know enough about the certificate authorities to actually comment.)

Off topic I'm sure, but this was probably a better strategy than to invest with Bernard L. Madoff Investment Securities LLC.

Phil
Post Reply