Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #817 > unrolled thread

Lauren Weinstein on "trusted proxies"

Back to article view | Back to comp.misc

Contents

  Lauren Weinstein on "trusted proxies" RS Wood <rswood@therandymon.com> - 2014-02-23 22:47 +0000
    Re: Lauren Weinstein on "trusted proxies" Whiskers <catwheezel@operamail.com> - 2014-02-24 13:43 +0000
      Re: Lauren Weinstein on "trusted proxies" Bjoern Hoehrmann <bjoern@hoehrmann.de> - 2014-02-24 16:30 +0100
      Re: Lauren Weinstein on "trusted proxies" Dave Garland <dave.garland@wizinfo.com> - 2014-02-24 10:39 -0600
      Re: Lauren Weinstein on "trusted proxies" "q.kontinuum" <achsis_of_elvis@yahoo.co.uk> - 2014-02-25 18:37 +0100
        Re: Lauren Weinstein on "trusted proxies" Whiskers <catwheezel@operamail.com> - 2014-02-25 22:40 +0000
          Re: Lauren Weinstein on "trusted proxies" "q.kontinuum" <achsis_of_elvis@yahoo.co.uk> - 2014-02-26 23:44 +0100
            Re: Lauren Weinstein on "trusted proxies" Marko Rauhamaa <marko@pacujo.net> - 2014-02-27 01:00 +0200
              Re: Lauren Weinstein on "trusted proxies" "q.kontinuum" <achsis_of_elvis@yahoo.co.uk> - 2014-02-27 06:12 +0100
                Re: Lauren Weinstein on "trusted proxies" Marko Rauhamaa <marko@pacujo.net> - 2014-02-27 08:48 +0200
                Re: Lauren Weinstein on "trusted proxies" Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-27 08:35 +0000
                  Re: Lauren Weinstein on "trusted proxies" Marko Rauhamaa <marko@pacujo.net> - 2014-02-27 11:01 +0200
                    Re: Lauren Weinstein on "trusted proxies" Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-27 15:07 +0000
                      Re: Lauren Weinstein on "trusted proxies" "q.kontinuum" <achsis_of_elvis@yahoo.co.uk> - 2014-02-28 08:06 +0100
                        Re: Lauren Weinstein on "trusted proxies" Marko Rauhamaa <marko@pacujo.net> - 2014-02-28 10:02 +0200
                          Re: Lauren Weinstein on "trusted proxies" "q.kontinuum" <achsis_of_elvis@yahoo.co.uk> - 2014-02-28 09:24 +0100
                            Re: Lauren Weinstein on "trusted proxies" Marko Rauhamaa <marko@pacujo.net> - 2014-02-28 12:04 +0200
                              Re: Lauren Weinstein on "trusted proxies" Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-28 11:31 +0000

#817 — Lauren Weinstein on "trusted proxies"

I "borrowed" this from Hacker News, where there are just a few comments 
at present, so still time to jump in ...

http://lauren.vortex.com/archive/001076.html

Choice quote:

What they propose for the new HTTP/2.0 protocol is nothing short of 
officially sanctioned snooping.

Of course, they don't phrase it exactly that way.

You see, one of the "problems" with SSL/TLS connections (e.g. https:) -- 
from the standpoint of the dominant carriers anyway -- is that the 
connections are, well, fairly secure from snooping in transit (assuming 
your implementation is correct ... right?)

But some carriers would really like to be able to see that data in the 
clear -- unencrypted. This would allow them to do fancy caching 
(essentially, saving copies of data at intermediate points) and 
introduce other "efficiencies" that they can't do when your data is 
encrypted from your client to the desired servers (or from servers to 
client).

When data is unencrypted, "proxy servers" are a routine mechanism for 
caching and passing on such data. But conventional proxy servers won't 
work with data that has been encrypted end-to-end, say with SSL.

So this dandy proposal offers a dandy solution: "Trusted proxies" -- or, 
to be more straightforward in the terminology, "man-in-the-middle 
attack" proxies. Oh what fun.

[toc] | [next] | [standalone]

#845

On 2014-02-23, RS Wood <rswood@therandymon.com> wrote:
> I "borrowed" this from Hacker News, where there are just a few comments 
> at present, so still time to jump in ...
>
> http://lauren.vortex.com/archive/001076.html

[...]

> When data is unencrypted, "proxy servers" are a routine mechanism for 
> caching and passing on such data. But conventional proxy servers won't 
> work with data that has been encrypted end-to-end, say with SSL.
>
> So this dandy proposal offers a dandy solution: "Trusted proxies" -- or, 
> to be more straightforward in the terminology, "man-in-the-middle 
> attack" proxies. Oh what fun.

It's a working group draft, which I think is some way short of being a
proposal.  The document is part of a continuing debate about possible
ways of improving efficiency without compromising privacy - eg if a user
is willing for an encrypted Wiki session to be 'proxied' by a carrier
then they can be given the option to permit that, so that the carrier
can supply the same Wiki page to other users without transferring the
data from the Wiki server itself every time.  It would still be possible
for users to specify that no proxy should be used when accessing their
bank account or other /really/ confidential stuff.  

Of course, the existence of a 'trusted proxy' system would introduce the
worry that a user's preference that a particular session not be proxied,
might be ignored.

<http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01>

Perhaps the real problem is that many things are being encrypted in
transit, which do not need to be.  When I log in to my bank, for
example, the fact that I am connecting to the bank is not concealed by
the encryption; so why do the bank's logo, public announcements,
advertising, terms and conditions, etc, need to be encrypted along with
my personal information?  Carriers and content-providers need to
co-operate more over the design of web services with efficiency in mind.
Only encrypt what needs to be encrypted; the rest can be 'in clear' and
proxied without harm.

-- 
-- ^^^^^^^^^^
--  Whiskers 
-- ~~~~~~~~~~

[toc] | [prev] | [next] | [standalone]

#850

* Whiskers wrote in comp.misc:
>It's a working group draft, which I think is some way short of being a
>proposal.

The document `draft-loreto-httpbis-trusted-proxy20-01` is an individual
submission and has no official standing in the IETF of any kind. Anyone
can upload a document like it and it would be automatically published on
the IETF servers.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[toc] | [prev] | [next] | [standalone]

#854

On 2/24/2014 7:43 AM, Whiskers wrote:

> Perhaps the real problem is that many things are being encrypted in
> transit, which do not need to be.  When I log in to my bank, for
> example, the fact that I am connecting to the bank is not concealed by
> the encryption; so why do the bank's logo, public announcements,
> advertising, terms and conditions, etc, need to be encrypted along with
> my personal information?  Carriers and content-providers need to
> co-operate more over the design of web services with efficiency in mind.
> Only encrypt what needs to be encrypted; the rest can be 'in clear' and
> proxied without harm.
> 

If you only encrypt the "important" stuff, you have greatly simplified
the attacker's task, as you have shown them exactly what
communications to concentrate on. And narrowed down the possibilities
for what the cleartext might be.

Rather, if there is any need at all for encryption (and there is),
it's best to encrypt _everything_. It makes a lot more work for the
attacker.

[toc] | [prev] | [next] | [standalone]

#923

On 2014-02-24, Whiskers <catwheezel@operamail.com> wrote:
> proposal.  The document is part of a continuing debate about possible
> ways of improving efficiency without compromising privacy - eg if a user
> is willing for an encrypted Wiki session to be 'proxied' by a carrier
> then they can be given the option to permit that, so that the carrier
> can supply the same Wiki page to other users without transferring the
> data from the Wiki server itself every time.

Maybe I'm missing something here, but shouldn't this already be
possible? A MITM-Attack works, but the browser will pop up a warning
stating that the ssl-key does not match the requested domain. If the
data is not important, most users could chose to ignore the
warning.

-- 
Trolling is a art!

My public-key is available on http://tinyurl.com/ps9r99y

[toc] | [prev] | [next] | [standalone]

#938

On 2014-02-25, q.kontinuum <achsis_of_elvis@yahoo.co.uk> wrote:
> On 2014-02-24, Whiskers <catwheezel@operamail.com> wrote:
>> proposal.  The document is part of a continuing debate about possible
>> ways of improving efficiency without compromising privacy - eg if a
>> user is willing for an encrypted Wiki session to be 'proxied' by a
>> carrier then they can be given the option to permit that, so that the
>> carrier can supply the same Wiki page to other users without
>> transferring the data from the Wiki server itself every time.
>
> Maybe I'm missing something here, but shouldn't this already be
> possible? A MITM-Attack works, but the browser will pop up a warning
> stating that the ssl-key does not match the requested domain. If the
> data is not important, most users could chose to ignore the warning.

Not quite.  Your browser only warns you about an unknown certificate if
it actually gets a certificate it doesn't recognise; it may or may not
alert you if the server switches to un-encrypted mode - early 'man in
the middle' attackers did exactly that - and it won't alert you if it
gets a certificate it does recognise.  Some attackers have acquired
genuine certificates which your browser probably won't object to, and
some users have been tricked into installing the attacker's own
certificate.  So SSL on its own isn't enough to protect everyone all the
time; there is still an element of trust involved, and users still need
to be vigilant.

-- 
-- ^^^^^^^^^^
--  Whiskers 
-- ~~~~~~~~~~

[toc] | [prev] | [next] | [standalone]

#1017

On 2014-02-25, Whiskers <catwheezel@operamail.com> wrote:
> On 2014-02-25, q.kontinuum <achsis_of_elvis@yahoo.co.uk> wrote:
> the middle' attackers did exactly that - and it won't alert you if it
> gets a certificate it does recognise.  Some attackers have acquired
> genuine certificates which your browser probably won't object to, 

But the certificate is usually bound to a domain name. So, if I visit
https://bank.com, the attacker needs a certifficate issued for
bank.com to fool my browser. (Or at least he needs to redirect me
somehow to https://bamk.com and own a certificate of *that* site.)

At least thats how I learned it.

-- 
Trolling is a art!

My public-key is available on http://tinyurl.com/ps9r99y

[toc] | [prev] | [next] | [standalone]

#1018

"q.kontinuum" <achsis_of_elvis@yahoo.co.uk>:

> But the certificate is usually bound to a domain name. So, if I visit
> https://bank.com, the attacker needs a certifficate issued for
> bank.com to fool my browser. (Or at least he needs to redirect me
> somehow to https://bamk.com and own a certificate of *that* site.)

There are numerous companies whose certificates are given the green
light by the web browsers. You need to find the certificate authority
with least scruples to gain a valid certificate for a domain.

I was once involved in buying a certificate for a domain. I supplied
information to a web form. They accepted the application after verifying
that my application was legitimate.

How did they verify my application was legitimate? I satisfied their two
stringent requirements:

  1. They received the payment.

  2. I picked up the phone when they called the number I had entered on
     the certificate application form.


IOW, all a valid certificate proves is it has been paid for.


Marko

[toc] | [prev] | [next] | [standalone]

#1022

On 2014-02-26, Marko Rauhamaa <marko@pacujo.net> wrote:
> "q.kontinuum" <achsis_of_elvis@yahoo.co.uk>:
> IOW, all a valid certificate proves is it has been paid for.

Ok, the concept is called chain of *trust* authority for a reason. An
improvement might be if the Browser would make the chain of trust
visible and configurable by user. (Maybe it would be sufficient to be
able to remove CAs from the browser.)

I didn't want to claim the implementation is secure in praxis (your
anectdotal evidence shows it isn't), just wanted to point out the
*concept* is already good and wouldn't need to be amended to allow
transparent proxies.

-- 
Trolling is a art!

My public-key is available on http://tinyurl.com/ps9r99y

[toc] | [prev] | [next] | [standalone]

#1023

"q.kontinuum" <achsis_of_elvis@yahoo.co.uk>:

> Ok, the concept is called chain of *trust* authority for a reason.

Aka the as-strong-as-its-weakest-link security scheme.

> the *concept* is already good and wouldn't need to be amended to allow
> transparent proxies.

Yes, if you could remove the chain of trust part, the rest is very good.


Marko

[toc] | [prev] | [next] | [standalone]

#1024

In message <82u2ua-mfl.ln1@7398004cd8ad880124144d3c685567d7.anonymous> 
  q.kontinuum <achsis_of_elvis@yahoo.co.uk> wrote:
> On 2014-02-26, Marko Rauhamaa <marko@pacujo.net> wrote:
>> "q.kontinuum" <achsis_of_elvis@yahoo.co.uk>:
>> IOW, all a valid certificate proves is it has been paid for.

> Ok, the concept is called chain of *trust* authority for a reason. An
> improvement might be if the Browser would make the chain of trust
> visible and configurable by user. (Maybe it would be sufficient to be
> able to remove CAs from the browser.)

The fundamental problem is that SSL certificates are supposed to do
double duty.

1) Prove identity (they fail, spectacularly, at this)
2) Provide security (they mostly work at this, but then fail
spectacularly)

For the most part, what people need is security, as identity is largely
useless. Yes, you want identity with your bank or amazon, but for most
site, you don't care, you just want a secure connection from you to
them.

> I didn't want to claim the implementation is secure in praxis (your
> anectdotal evidence shows it isn't), just wanted to point out the
> *concept* is already good and wouldn't need to be amended to allow
> transparent proxies.

The entire CA/certificate model is fundamentally and irrevocably broken.
there are too many CAs, there are too many problems within those CAs,
and there are far too many examples of perfectly valid certs with
completely invalid information in them that pass the CA checks until
someone figures out, "Oh, oops. Darn."

-- 
When the routine bites hard / and ambitions are low And the resentment
rides high / but emotions won't grow And we're changing our ways, /
taking different roads Then love, love will tear us apart again

[toc] | [prev] | [next] | [standalone]

#1026

Lewis <g.kreme@gmail.com.dontsendmecopies>:

> The entire CA/certificate model is fundamentally and irrevocably
> broken.

Well, it's the modern-day organized religion. You want a CA to sprinkle
holy water on your website. Your browser correctly indicates if your
connection has been blessed.


Marko

[toc] | [prev] | [next] | [standalone]

#1038

In message <87k3chylno.fsf@elektro.pacujo.net> 
  Marko Rauhamaa <marko@pacujo.net> wrote:
> Lewis <g.kreme@gmail.com.dontsendmecopies>:

>> The entire CA/certificate model is fundamentally and irrevocably
>> broken.

> Well, it's the modern-day organized religion. You want a CA to sprinkle
> holy water on your website. Your browser correctly indicates if your
> connection has been blessed.

Yes, and it's about that effective.

The only cert I use is a self-signed cert for the mail server. I figure
if anyone has a problem with a self-signed cert when checking mail, then
they have no business using my mail server.

-- 
"Oh damn", said Maladict.

[toc] | [prev] | [next] | [standalone]

#1065

On 2014-02-27, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> The only cert I use is a self-signed cert for the mail server. I figure
> if anyone has a problem with a self-signed cert when checking mail, then
> they have no business using my mail server.

I do the same for my zarafa exchange-server-clone; however, to avoid
mitm attacks you should deploy it to the device via a trusted
channel... 

-- 
Trolling is a art!

My public-key is available on http://tinyurl.com/ps9r99y

[toc] | [prev] | [next] | [standalone]

#1069

"q.kontinuum" <achsis_of_elvis@yahoo.co.uk>:

> I do the same for my zarafa exchange-server-clone; however, to avoid
> mitm attacks you should deploy it to the device via a trusted
> channel...

And even when you think you've done everything by the book, can you
trust your software and hardware? I have an SSH client on my cell phone;
my key and passphrase are probably safe with the NSA (or whatever outfit
is behind the app).

And even if I wrote the compiler, client/server software and OS myself,
the keyboard logger might be built in on the motherboard.


Marko

[toc] | [prev] | [next] | [standalone]

#1072

On 2014-02-28, Marko Rauhamaa <marko@pacujo.net> wrote:
> "q.kontinuum" <achsis_of_elvis@yahoo.co.uk>:
>
>> I do the same for my zarafa exchange-server-clone; however, to avoid
>> mitm attacks you should deploy it to the device via a trusted
>> channel...
>
> And even when you think you've done everything by the book, can you
> trust your software and hardware?

No, definitely not. I have a Windows Phone ;-) (Not kidding.)
But seriously: Even Cyanogen Androids have binary driver loaded. As
long as hardware specification is not open, there won't be a really
trustworthy device, neither Android not WP not iOS nor Tizen,
Sailfish, Ubuntu.

Nevertheless I think it's worth the effort to do our part on the
accessible levels of the whole system, hoping that there are always
people interested in lower layers, analyzing them for hidden backdoors
and so on. Until now, even the Snowden documents (as far as I
remember) do not indicate hacking on that level being standard
procedure. Only what data you willingly transfer to corporate servers
is used by the secret services. There were some articles about
hardware deliveries to specific targets being intercepted and bugged,
but so crudely that it's noticable. Of course this *could* be a false
flag by "them" to mull "us" in a false sense of security, but that way
of thinking is a short path to paranoia, I guess :-)


-- 
Trolling is a art!

My public-key is available on http://tinyurl.com/ps9r99y

[toc] | [prev] | [next] | [standalone]

#1079

"q.kontinuum" <achsis_of_elvis@yahoo.co.uk>:

> that way of thinking is a short path to paranoia, I guess :-)

As they say, just because you're paranoid doesn't mean they're not out
to get you.


Marko

[toc] | [prev] | [next] | [standalone]

#1091

In message <87d2i7y2n0.fsf@elektro.pacujo.net> 
  Marko Rauhamaa <marko@pacujo.net> wrote:
> "q.kontinuum" <achsis_of_elvis@yahoo.co.uk>:

>> that way of thinking is a short path to paranoia, I guess :-)

> As they say, just because you're paranoid doesn't mean they're not out
> to get you.

I think recent revelations have proved that no one, not even the guys
literally wearing tinfoil hats, was sufficiently paranoid.

-- 
NO. I CANNOT BE BIDDEN. I CANNOT BE FORCED. I WILL DO ONLY THAT WHICH I
KNOW TO BE RIGHT. --Mort

[toc] | [prev] | [standalone]

Back to top | Article view | comp.misc

csiph-web