Jeffrey Walton wrote:
On Sun, Jan 13, 2013 at 1:20 PM, Warren Kumari <[email protected]> wrote:
On Jan 12, 2013, at 4:27 AM, ianG <[email protected]> wrote:
On 11/01/13 02:59 AM, Jon Callas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
...
The Amazon FAQ for Silk did at least say:
"We will establish a secure connection from the cloud to the site owner on your
behalf for page requests of sites using SSL (e.g. https://siteaddress.com). Amazon Silk
will facilitate a direct connection between your device and that site. Any security
provided by these particular sites to their users would still exist."
while they were doing this.
There was some flap, grumpiness about this, see for example:
http://www.zdnet.com/blog/networking/amazons-kindle-fire-silk-browser-has-serious-security-concerns/1516
That's in contrast to my site's Terms of Service, which expressly forbids it.
NO UNLAWFUL INTERCEPTION
Software Integrity users expect end-to-end security. We prohibit
proxying or interception of communication for any protocols or ports
over any medium including, but not limited to, SSL/TLS, VPN, HTTP,
HTTPS, SHTTP, SMTP, SSMTP, IMAP, IMAP4-SSL, IMAPS, POP, and SSL-POP,
including electronic, analog or digital voice, analog or digital data,
wired, wireless, and cellular.
Assuming one of these Interception Accelerators visited my site on
behalf of a user, I believe that means they have exceeded their
authority. Perhaps I should ask someone like Weev what happens to
folks who do that (who was convicted of aggregating public data from a
public service hung off a public internet). Should I press for a CFAA
violation? Or should I ask for injunctive relief from the folks who
destroy the secure channel?
You may also request your users to authenticate with client digital
signature keys (you maintain your own trusted database of client-public
key relationships, as in the first party certification paradigm). Then
the MITM agents will not be in a position to impersonate your users.
You will have to explain to the users who can't connect that some MITM
agent was in their network path to your site. Maybe the security
criticalness of your site deserves such a cryptographic control.
Sometimes controls stand in the way of those who put them in place. But
cryptographic controls are meant to block traffic sometimes. I
understand you don't tolerate any exception for well-intentioned MITM
agents. At least this was the intent of those who developed the TLS
protocol.
In HTML RFC2616 Security Considerations section:
15.7 Proxies and Caching
By their very nature, HTTP proxies are men-in-the-middle, and
represent an opportunity for man-in-the-middle attacks. Compromise of
the systems on which the proxies run can result in serious security
and privacy problems. Proxies have access to security-related
information, personal information about individual users and
organizations, and proprietary information belonging to users and
content providers. A compromised proxy, or a proxy implemented or
configured without regard to security and privacy considerations,
might be used in the commission of a wide range of potential attacks.
Proxy operators should protect the systems on which proxies run as
they would protect any system that contains or transports sensitive
information. In particular, log information gathered at proxies often
contains highly sensitive personal information, and/or information
about organizations. Log information should be carefully guarded, and
appropriate guidelines for use developed and followed. (Section
15.1.1).
That's a fair description of MITM minefield.
In TLS 1.0 RFC2246 sections F.1.1.1 and F.1.1.2 you will see that the
TLS designers stated "server authentication is required in environments
where active man-in-the-middle attacks are a concern" and explained how
server authentication is effected.
Whether service agreements refer to these notions when they pretend to
offer a secure connection could be argued in an arbitration forum, but
this should be clear for the "experts" on this list.
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
