KDEPIM 4.6 prob^Wimpressions

[Duncan]

J posted on Tue, 26 Jul 2011 15:31:03 -0400 as excerpted:

[Alex posted...]

>> If you don't mind, I have one more questions on this. How bad is the
>> security impact? For example, my online banking site is
>> https://banking.postbank.de , probably one of the most used banking
>> sites in Germany. How big is the risk of using it? Would you do this?
>> What can be done to minimize the risk? Other than using Firefox and
>> simply not seeing the warning dialog :)

> Overall the security isn't a big issue, but the "trust" that comes from
> the certificate is the issue.  The warning message means that the
> certificate presented could not be matched up to the corporation (in
> this case the bank) using the available chain of "trusted" certificates
> that already exist in the browser or presented by the web server.   The
> encryption is still there and does it's job, you just cannot be sure
> that the bank actually sent this certificate to you or is some "man in
> the middle" sent it instead.

Exactly.

There's a couple ways around that.

One is verifying the bank cert via other methods.  Call them up and ask 
them to put the cert on a USB stick or something and send it to you, or 
visit a branch and ask there.

A different method of doing the same thing would be to surf to the site 
via different connections (or ask someone else to verify the info from 
their connection) so someone would have to be MitM-ing all of them in 
ordered to successfully deceive you.  I did this when my bank had some 
certificate issue of some sort at one point, posting a request for people 
to verify it from other locations, which they did.

The other method is to simply take your chances the first time 
(preferably do it over a wired connection that you trust, not over a wifi 
or from the library or whatever, no use taking needless risks) and 
permanently accept the certificate, then rely on the notification you'd 
get if it changed to detect interference from then on.  As long as you 
aren't doing something stupid like verifying it for the first time over 
public wifi at the airport, the chances of the first connection being a 
bad one are pretty slim.

This "accept it the first time, then don't worry about it unless it 
changes" method, is pretty much the way SSH key authentication works.  
You get prompted the first time and generally assume everything's fine (a 
few folks verify the fingerprint via other means too, but not many), and 
don't worry about it after that unless you get prompted again, meaning 
the certificate at the other end isn't the one that was expected, so 
there's a good chance it's not the other end after all (unless of course 
you know that they changed their cert, perhaps because you did it as the 
admin, yourself, or it can also happen if the fingerprint info at your 
end got deleted.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.