[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: ssl auth failure gui: does "continue" do what I think it does?
From:       Jeff Mitchell <mitchell () kde ! org>
Date:       2009-06-09 18:01:46
Message-ID: 4A2EA38A.1080403 () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Matthew Woehlke wrote:
> Jeff Mitchell wrote:
>> Matthew Woehlke wrote:
>>>> But there isn't a choice.  Certificates are essentially the only
>>>> encryption method feasible for most sites, because of e.g. browser
>>>> support.  So if all you need is encryption, and not authentication, you
>>>> still have to use the same system.
>>> But *you don't get encryption* this way
>> But you do. [S]aying it's not [...] is factually wrong.
> 
> Humph. Apparently wiktionary agrees with you, defining "encryption" as 
> "the process of obscuring information to make it unreadable without 
> special knowledge, key files, and/or passwords."
> 
> ...which means that rot13 is "encryption".

Poor encryption, but encryption.

> So... let me clarify. You don't have* /end-to-end/ encryption.
> (* To be clear, you /might/ have end-to-end encryption, but you have no 
> way of knowing.)

No, you can always know if you have end-to-end encryption.  You just
don't know who's on the other end.  :-)

End-to-end encryption signifies that the connection is encrypted from
one endpoint to the other.  In a MitM attack, the endpoint isn't who you
think it is -- but your connection to that MitM is end-to-end encrypted,
unless combined a situation like the below example.

An example where you would *not* have end-to-end encryption would be two
branches of a company that have a VPN link between them, connecting the
corporate LAN.  When a user at site A makes a HTTP connection to a
server at site B, that HTTP connection is not encrypted, but the traffic
passing through the Internet from one site to the next *is* encrypted.
So this connection has non end-to-end encryption.  If the user made a
HTTPS connection instead, it would be end-to-end encryption.  Note that
this makes a difference as to which entities are performing the
encryption, hence, you know whether or not your encryption is end-to-end.

So combining them, if another server inside the corporate LAN is
performing a MitM attack, it's the same deal.  If you're making a HTTP
connection, part of your connection is encrypted, but not end-to-end
(and you know this).  If you're making a HTTPS connection, you are
end-to-end encrypted, and you know it, but what you don't know is that
you're not end-to-end encrypted with the end host that you expect.
(Hence, authentication being necessary for security, as you are very aware.)

--Jeff


["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]