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

Groups > comp.lang.python > #91044 > unrolled thread

Ah Python, you have spoiled me for all other languages

Back to article view | Back to comp.lang.python

Contents

  Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-05-23 00:58 +1000
    Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-23 01:29 +1000
      Re: Ah Python, you have spoiled me for all other languages wxjmfauth@gmail.com - 2015-05-22 10:57 -0700
      Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-22 16:40 -0500
      Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-22 16:40 -0500
        Re: Ah Python, you have spoiled me for all other languages Terry Reedy <tjreedy@udel.edu> - 2015-05-22 21:54 -0400
          Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-23 06:12 -0500
          Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-23 06:12 -0500
            Re: Ah Python, you have spoiled me for all other languages Terry Reedy <tjreedy@udel.edu> - 2015-05-23 13:26 -0400
        Re: Ah Python, you have spoiled me for all other languages Michael Torrie <torriem@gmail.com> - 2015-05-22 21:31 -0600
          Re: Ah Python, you have spoiled me for all other languages Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-05-23 08:55 +0200
            Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-23 06:21 -0500
              Re: Ah Python, you have spoiled me for all other languages Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-05-23 15:24 +0200
                Re: Ah Python, you have spoiled me for all other languages Marko Rauhamaa <marko@pacujo.net> - 2015-05-23 20:05 +0300
                  Re: Ah Python, you have spoiled me for all other languages Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-05-24 20:29 +0200
            Re: Ah Python, you have spoiled me for all other languages Marko Rauhamaa <marko@pacujo.net> - 2015-05-23 15:44 +0300
              Re: Ah Python, you have spoiled me for all other languages Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-05-23 15:17 +0200
              Re: Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-05-24 00:00 +1000
                Re: Ah Python, you have spoiled me for all other languages Marko Rauhamaa <marko@pacujo.net> - 2015-05-23 19:53 +0300
                  Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-24 03:41 +1000
                    Re: Ah Python, you have spoiled me for all other languages Marko Rauhamaa <marko@pacujo.net> - 2015-05-23 22:02 +0300
                  Re: Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-05-24 20:26 +1000
                    Re: Ah Python, you have spoiled me for all other languages Marko Rauhamaa <marko@pacujo.net> - 2015-05-24 18:26 +0300
                      Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-25 01:35 +1000
                        Re: Ah Python, you have spoiled me for all other languages Marko Rauhamaa <marko@pacujo.net> - 2015-05-25 09:57 +0300
                          Re: Ah Python, you have spoiled me for all other languages Laura Creighton <lac@openend.se> - 2015-05-25 11:39 +0200
                          Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-25 21:09 +1000
              Re: Ah Python, you have spoiled me for all other languages Michael Torrie <torriem@gmail.com> - 2015-05-23 21:00 -0600
                Re: Ah Python, you have spoiled me for all other languages Marko Rauhamaa <marko@pacujo.net> - 2015-05-24 11:23 +0300
        Re: Ah Python, you have spoiled me for all other languages Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-22 22:10 -0600
        Re: Ah Python, you have spoiled me for all other languages amber <amber.of.luxor@gmail.com> - 2015-05-23 04:11 +0000
          Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-23 06:11 -0500
          Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-23 06:11 -0500
        Re: Ah Python, you have spoiled me for all other languages Ben Finney <ben+python@benfinney.id.au> - 2015-05-23 14:20 +1000
        Re: Ah Python, you have spoiled me for all other languages Michael Torrie <torriem@gmail.com> - 2015-05-22 22:30 -0600
          Re: Ah Python, you have spoiled me for all other languages Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-23 11:10 +0000
            Re: Ah Python, you have spoiled me for all other languages Tim Chase <python.list@tim.thechases.com> - 2015-05-23 06:34 -0500
            Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-23 21:40 +1000
            Re: Ah Python, you have spoiled me for all other languages Michael Torrie <torriem@gmail.com> - 2015-05-23 20:57 -0600
            Re: Ah Python, you have spoiled me for all other languages Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-24 01:22 -0600
        Re: Ah Python, you have spoiled me for all other languages Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-22 22:29 -0600
        Re: Ah Python, you have spoiled me for all other languages Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-22 22:49 -0600
        Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-23 14:49 +1000
          Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-23 06:29 -0500
        Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-23 14:55 +1000
        Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-23 14:28 +1000
        Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-23 14:21 +1000
      Re: Ah Python, you have spoiled me for all other languages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-23 14:33 +0200
        Re: Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-05-23 23:01 +1000
          Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-23 23:12 +1000
            Re: Ah Python, you have spoiled me for all other languages wxjmfauth@gmail.com - 2015-05-23 23:37 -0700
          Re: Ah Python, you have spoiled me for all other languages Ned Batchelder <ned@nedbatchelder.com> - 2015-05-23 06:35 -0700
            Re: Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-05-24 00:09 +1000
            Re: Ah Python, you have spoiled me for all other languages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-07 10:21 +0200
              Re: Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-06-07 21:42 +1000
                Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-06-07 22:08 +1000
                  Re: Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-06-07 23:24 +1000
                    Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-06-08 00:47 +1000
                Re: Ah Python, you have spoiled me for all other languages random832@fastmail.us - 2015-06-07 10:58 -0400
                  Re: Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-06-08 02:28 +1000
    Re: Ah Python, you have spoiled me for all other languages Tony the Tiger <tony@tiger.invalid> - 2015-05-22 16:31 +0000
      Re: Ah Python, you have spoiled me for all other languages Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-22 17:57 +0100
      Re: Ah Python, you have spoiled me for all other languages Tim Daneliuk <tundra@tundraware.com> - 2015-05-22 16:41 -0500
        Re: Ah Python, you have spoiled me for all other languages Tony the Tiger <tony@tiger.invalid> - 2015-05-23 20:25 +0000
    Re: Ah Python, you have spoiled me for all other languages Grant Edwards <invalid@invalid.invalid> - 2015-05-22 17:47 +0000
      Re: Ah Python, you have spoiled me for all other languages Chris Angelico <rosuav@gmail.com> - 2015-05-23 04:11 +1000
      Re: Ah Python, you have spoiled me for all other languages mm0fmf <none@mailinator.com> - 2015-05-22 19:19 +0100
      Re: Ah Python, you have spoiled me for all other languages Laura Creighton <lac@openend.se> - 2015-05-22 21:14 +0200
        Re: Ah Python, you have spoiled me for all other languages Steven D'Aprano <steve@pearwood.info> - 2015-05-23 11:36 +1000
      Re: Ah Python, you have spoiled me for all other languages MRAB <python@mrabarnett.plus.com> - 2015-05-22 20:34 +0100
      Re: Ah Python, you have spoiled me for all other languages Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-22 13:56 -0600
        Re: Ah Python, you have spoiled me for all other languages Marko Rauhamaa <marko@pacujo.net> - 2015-05-22 23:34 +0300
          Re: Ah Python, you have spoiled me for all other languages Tim Chase <python.list@tim.thechases.com> - 2015-05-22 15:55 -0500
          Re: Ah Python, you have spoiled me for all other languages Ethan Furman <ethan@stoneleaf.us> - 2015-05-22 14:15 -0700
          Re: Ah Python, you have spoiled me for all other languages Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-22 15:20 -0600
    Re: Ah Python, you have spoiled me for all other languages Paul Rubin <no.email@nospam.invalid> - 2015-05-22 16:00 -0700
      Re: Ah Python, you have spoiled me for all other languages Michael Torrie <torriem@gmail.com> - 2015-05-22 21:33 -0600

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#91148

Chris Angelico <rosuav@gmail.com>:

> On Sun, May 24, 2015 at 2:53 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Steven D'Aprano <steve@pearwood.info>:
>>> If you gave them veto power over all certificate authorities (since
>>> you need all four to agree, any of them can veto a CA),
>>
>> No, they wouldn't be able to veto a CA. At worst, they would be able
>> to refuse you a certificate. If they did that, they would risk being
>> dropped from the power pool.
>
> You start out by saying it's valid if vouched for by X, Y, Z., *and*
> A. That means that if it's vouched for by X, Y, and A, but not Z, then
> it's not valid. That gives Z the power to veto any certificate.
> Correspondingly each of the others.

CA = certificate authority != certificate


Marko

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

#91167

On Sun, 24 May 2015 02:53 am, Marko Rauhamaa wrote:

> Steven D'Aprano <steve@pearwood.info>:
> 
>> On Sat, 23 May 2015 10:44 pm, Marko Rauhamaa wrote:
>>> Here's an idea: an authentication is considered valid if it is
>>> vouched for by the United States, China, Russia *and* the European
>>> Union. Those governments are the only entities that would have the
>>> right to delegate their respective certification powers to private
>>> entities.
>>
>> An interesting mix of:
>>
>> - one explicitly non-democratic one-party state;
>> - one nominally democratic but de facto autocratic state;
>> - one nominally democratic but de facto two-party corporatocracy;
>> - one supranational union of states;
> 
> Yes, the same principles that make UN do a lot of good in the world
> despite those shortcomings.
> 
>> If you gave them veto power over all certificate authorities (since
>> you need all four to agree, any of them can veto a CA),
> 
> No, they wouldn't be able to veto a CA. At worst, they would be able to
> refuse you a certificate. If they did that, they would risk being
> dropped from the power pool.

That's not what you said. You said, and I quote:

"an authentication is considered valid if it is vouched for by the United
States, China, Russia *and* the European Union."

[Emphasis in the original.]

So if (let's say) the US, China and Russia all agree that a Certs-R-Us are a
legitimate CA, but the EU disagrees for some reason. Then certificates
issued by Certs-R-Us will *not* be accepted as valid. Hence the EU has veto
power over CAs, and by extension, certificates. And likewise any of the
others: it only takes one refusal for the certificate to be invalid.

If the certificate is *not* invalidated, then people can trust certificates
regardless of whether they are vouched for by all four states (counting the
EU as a state for simplicity) or not. If I can choose to trust Certs-R-Us
despite the failure of the EU to vouch for them, then I can equally trust
*any* CA, whether they are vouched for by all four states or by none of
them. Which brings us right back to the present system.

(And by the way, I'd be more inclined to trust a CA that was vouched for by,
say, the Norwegian government than one vouched for by the Russian
government.)

And what's this "dropped from the power pool" business? You never mentioned
a mechanism for removing a state from the privileged group. Who has
authority to do that?

If it's too hard to change the four-state solution ("What, we have to
completely redesign the entire Internet, again?") then they will never be
removed no matter how they abuse their privilege. If it is too easy ("just
edit /etc/ca-approvals"), then we'll have chaos where nobody agrees on who
can authorise CAs. Somewhere in the middle there's a point where the four
states will never refuse a CA, no matter how dodgy, lest they get kicked
out. In which case we haven't really solved the problem we're trying to
solve, just moved it around a bit.


>>> The governments would also offer to certify anybody in the world free
>>> of charge.
>>
>> Why would they do that?
> 
> They would have something to gain and something to lose:
> 
>  1. They would gain protection for their citizens and companies against
>     foreign MitM attacks.
> 
>  2. They would lose the power to perform MitM attacks on their own
>     citizens.
> 
> Unfortunately, the governments of the world fear their own citizens more
> than each other, so they would likely not go with the kind of plan I
> presented.

Charles Stross has some interesting ideas on that. The economic and
political elites are clamping down on dissent as a preemptive
counter-revolution:

http://www.antipope.org/charlie/blog-static/2013/07/who-ordered-that.html
 
> At the moment any sovereign government and sizeable criminal outfit 

Or medium sized corporation. Oh wait, I see you already mentioned criminal
outfits.


> can cook up valid certificates for any website in the world. That's
> because each CA is trusted completely.

I'm not sure that it is much of a benefit to swap from a free-market
reputation based system to a four-party oligopoly




-- 
Steven

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

#91189

Steven D'Aprano <steve@pearwood.info>:

> On Sun, 24 May 2015 02:53 am, Marko Rauhamaa wrote:
> "an authentication is considered valid if it is vouched for by the United
> States, China, Russia *and* the European Union."
>
> [Emphasis in the original.]
>
> So if (let's say) the US, China and Russia all agree that a Certs-R-Us are a
> legitimate CA,

I never proposed those countries should agree on a legitimate CA. Each
country would have their distinct, respective sets of CAs. A website
would be considered legitimate only if it possessed certificates from
all of the four domains.

> but the EU disagrees for some reason. Then certificates issued by
> Certs-R-Us will *not* be accepted as valid. Hence the EU has veto
> power over CAs, and by extension, certificates. And likewise any of
> the others: it only takes one refusal for the certificate to be
> invalid.

For the scheme to work, the countries would agree never to refuse to
certify a legitimate entity.

> (And by the way, I'd be more inclined to trust a CA that was vouched
> for by, say, the Norwegian government than one vouched for by the
> Russian government.)

You'd be asked to trust a server if it were vouched for by four CAs from
four independent power blocks. It would be in the power blocks'
interests to do their certification work properly because sloppiness
would only benefit their "adversaries."

> And what's this "dropped from the power pool" business? You never
> mentioned a mechanism for removing a state from the privileged group.
> Who has authority to do that?

A mechanism like that would have to be fleshed out in detail. There
could be many variations. But the main point is that no single
government or CA should have the means to spoof a peer.

> I'm not sure that it is much of a benefit to swap from a free-market
> reputation based system to a four-party oligopoly

The CA system is not based on reputation. Anybody in the world has an
equal right to become a root CA. You only need to convince the
OS/browser vendors:

   https://bugzilla.mozilla.org/show_bug.cgi?id=647959


The oligopoly would fail if the US, Russia, China and EU conspired
against a particular peer. Can you see that happening?


Marko

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

#91193

On Mon, May 25, 2015 at 1:26 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Steven D'Aprano <steve@pearwood.info>:
>
>> On Sun, 24 May 2015 02:53 am, Marko Rauhamaa wrote:
>> "an authentication is considered valid if it is vouched for by the United
>> States, China, Russia *and* the European Union."
>>
>> [Emphasis in the original.]
>>
>> So if (let's say) the US, China and Russia all agree that a Certs-R-Us are a
>> legitimate CA,
>
> I never proposed those countries should agree on a legitimate CA. Each
> country would have their distinct, respective sets of CAs. A website
> would be considered legitimate only if it possessed certificates from
> all of the four domains.

You've added extra levels of indirection, but it comes to the same
thing. You're requiring that everyone who wants to conduct business on
the internet (taking credit card numbers etc) has to go through four
separate authentication processes, and a failure in any one of them
means the site is not considered legit.

> For the scheme to work, the countries would agree never to refuse to
> certify a legitimate entity.

Right. And "legitimate" is defined as "not refused by any of the four
countries". All they have to do is decide that something's not
legitimate, and bam, they're off air. ANY ONE of your four has this
power of veto.

ChrisA

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

#91194

Chris Angelico <rosuav@gmail.com>:

> You've added extra levels of indirection, but it comes to the same
> thing. You're requiring that everyone who wants to conduct business on
> the internet (taking credit card numbers etc) has to go through four
> separate authentication processes, and a failure in any one of them
> means the site is not considered legit.

Yes. What you get is some much higher-level security than at the moment.

You could do with passport-level security with a single national
government but then you would be prone to attacks (or blunders) from
that government.

> Right. And "legitimate" is defined as "not refused by any of the four
> countries". All they have to do is decide that something's not
> legitimate, and bam, they're off air. ANY ONE of your four has this
> power of veto.

Certificates can be revoked, kinda, yes. Or more to the point,
roadblocks could be put in the way of certifying some applicants.
However, if that started happening, the OS and browser makers would
simply drop the obnoxious government from the prestigious club. It
really wouldn't be in their interests to start acting up.


Marko

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

#91196

In a message of Mon, 25 May 2015 09:57:28 +0300, Marko Rauhamaa writes:
>Certificates can be revoked, kinda, yes. Or more to the point,
>roadblocks could be put in the way of certifying some applicants.
>However, if that started happening, the OS and browser makers would
>simply drop the obnoxious government from the prestigious club. It
>really wouldn't be in their interests to start acting up.
'
Unfortunately, you cannot count on governments giving two hoots about
what you and I perceive as their interests.  Josef Stalin would just
go off and kill OS and browser makers in his country until he got
things the way he wanted it.  A US government more subservient to big
business could declare, for reasons of patriotism, national security,
and the ever popular 'to stop child pornography' that we all have to
use Windows software and run Microsoft browsers.

These are really bad ideas, even from the point of view of the
governments involved -- it would not accomplish anything like it was
supposed to accomplish (unless spreading fear and terror is the real
goal, in which case it might work great for that).  But having really
bad ideas and being willing to act on them is one of the
characteristics of the sort of obnoxious government we would like to
drop from the club, so no joy there.

What people need to understand is that unless you want to stamp out
freedom altogether, there will be crime.  You cannot have one without
the other, because all crime is, is 'somebody doing something that
some other people have said they are not allowed to do'.  You can have
quite a bit of crime without destroying the basic decent kindness that
most people have for each other.  Everybody says 'tisk tisk' and goes
on helping each other and being decent to each other.  But systematic
oppression, especially state-advocated opression done by the state
cuts to the heart of things and kills such goodwill and spontaneous
kindness dead.

Laura

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

#91199

On Mon, May 25, 2015 at 7:39 PM, Laura Creighton <lac@openend.se> wrote:
> What people need to understand is that unless you want to stamp out
> freedom altogether, there will be crime.

Or stamp out legislation altogether and have complete anarchy. There's
no such thing as crime among animals, because there's no law beyond
"survive".

The solution isn't to try to eliminate crime, but to cope with it.
Same with our own errors: accept and acknowledge that you WILL make
mistakes, and cope with that. In a spiritual sense, that might define
your religion; in a programming sense, that's exactly why we have
source control, so we can find out what happened (and why) and fix
problems once we find them. Would you use a program that got launched
as version 1 and never changed? Would you trust it on the basis that
it clearly has no bugs, because nobody's ever needed to fix any? I
certainly wouldn't.

Some things work well centralized, because differences are worse than
slight benefits one way or another. In any given country, we usually
all drive on the same side of the road. But a lot of things work
better *de*centralized, so that if one person makes a mistake, other
people can do things differently, and hindsight evaluation lets us
choose which one to encourage. PyPI is decentralized; the Python
standard library is centralized. The guardians of the latter are
rightly slow to choose from multiple alternatives, preferring to let
the decentralized collective mind of the former figure out which is
the clear best - if there even is one.

The best form of security is probably the GPG web of trust, being
fundamentally decentralized and based on personal reputation. Imagine
if, once you register a domain, you go talk to someone about getting a
GPG key signed for it - or, better still, sign the server's key
yourself, if you have a decent WoT for your own key (which I don't).
It wouldn't be hard to use self-signed SSL certificates, sign those
certs with a GPG key, and then let people download and install certs
for anyone they consider trustworthy. In fact, this seems so obvious
that I'm sure it's already been done. Trouble is, GPG isn't nearly
well enough known for mass use... but it is going to be a lot more
reliable than anything that depends on four countries' governments [1]
agreeing.

ChrisA

[1] Yes, technically the United States of Europe is not a country. But
just how structurally different is it from the United States of
America?

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

#91157

On 05/23/2015 06:44 AM, Marko Rauhamaa wrote:
> Johannes Bauer <dfnsonfsduifb@gmx.de>:
> 
>> I dislike CAs as much as the next guy. But the problem of distributing
>> trust is just not easy to solve, a TTP is a way out. Do you have an
>> alternative that does not at the same time to providing a solution
>> also opens up obvious attack surface?
> 
> Here's an idea: an authentication is considered valid if it is vouched
> for by the United States, China, Russia *and* the European Union. Those
> governments are the only entities that would have the right to delegate
> their respective certification powers to private entities. The
> governments would also offer to certify anybody in the world free of
> charge.

Why trust governments?  Why not use peer-to-peer trust.  If I trust you
and you trust site X with a fingerprint of Y, then I should trust it
also.  Sadly though getting the unwashed masses educated enough to make
this work is impossible (like how PGP is pretty much dead).  Maybe it's
a harder problem than anyone can solve.

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

#91164

Michael Torrie <torriem@gmail.com>:

> Why trust governments?

They have the means and are doing analogous things already wrt property
titles, passports, taxation, voting etc.

> Why not use peer-to-peer trust. If I trust you and you trust site X
> with a fingerprint of Y, then I should trust it also.

That's a huge leap of faith. Trust is not transitive.

I do trust the government far more than the word of mouth.


Marko

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

#91093

On Fri, May 22, 2015 at 9:31 PM, Michael Torrie <torriem@gmail.com> wrote:
> On 05/22/2015 07:54 PM, Terry Reedy wrote:
>> On 5/22/2015 5:40 PM, Tim Daneliuk wrote:
>>
>>> Lo these many years ago, I argued that Python is a whole lot more than
>>> a programming language:
>>>
>>>     https://www.tundraware.com/TechnicalNotes/Python-Is-Middleware/
>>
>> Perhaps something at tundraware needs updating.
>> '''
>> This Connection is Untrusted
>>
>> You have asked Firefox to connect securely to www.tundraware.com, but we
>> can't confirm that your connection is secure.
>>
>> Normally, when you try to connect securely, sites will present trusted
>> identification to prove that you are going to the right place. However,
>> this site's identity can't be verified.
>> '''
>
> Sigh. I blame this as much on the browser.  There's no inherent reason
> why a connection to a site secured with a self-signed certificate is
> insecure.  In fact it's definitely not.

Sure it is. Without some prior reason to trust the certificate, the
certificate is meaningless. How is the browser to distinguish between
a legitimate self-signed cert and a self-signed cert presented by an
attacker conducting a man-in-the-middle attack?

There is still some value in TLS with a self-signed certificate in
that at least the connection is encrypted and can't be eavesdropped by
an attacker who can only read the channel, but there is no assurance
that the party you're communicating with actually owns the public key
that you've been presented.

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

#91094

«»

On 22/05/2015 21:40, Tim Daneliuk wrote:
>    https://www.tundraware.com/TechnicalNotes/Python-Is-Middleware/
Quoting that article
«And no, you couldn't get a C based OS to do what TPF does even if you
did have a couple hundred million dollars to redo it, »

Why couldn't a C based OS do what TPF does?

My understanding is that if the programming language is Turing-Complete,
it can do anything that any other Turing-Complete language can do.  And
that assembler is a Turing-Complete language.

jonathon

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

#91111

On 05/22/2015 11:11 PM, amber wrote:
> «»
> 
> On 22/05/2015 21:40, Tim Daneliuk wrote:
>>    https://www.tundraware.com/TechnicalNotes/Python-Is-Middleware/
> Quoting that article
> «And no, you couldn't get a C based OS to do what TPF does even if you
> did have a couple hundred million dollars to redo it, »
> 
> Why couldn't a C based OS do what TPF does?
> 
> My understanding is that if the programming language is Turing-Complete,
> it can do anything that any other Turing-Complete language can do.  And
> that assembler is a Turing-Complete language.
> 
> jonathon
> 
> 
> 
> 


C could - in principle - do it.  As you point out, both are Turing Complete.
But, "in principle" is quite different than "in actual fact".  At the time
that article was written almost 15 years ago, the TPF systems in use
were running applications written in hand optimized assembly language on the
largest mainframes money could buy.  Everything about that environment was
optimized for speed - from partially populating disk surfaces to running the
thinnest possible operating system executive.  (In those days, TPF itself didn't 
even have memory protection, or at least, it was just being added as an OS
feature.)

The point is that it would have been nearly impossible technically to
rewrite all that in C and expect the same level of minimal path length/
max throughput.  Give the sheer transaction load on those machines, this
would have been a showstopper.

But that was then and this is now.  These days, much of that capability 
HAS been written in higher level languages because of scale-out architectures
and messaging/queuing middleware.  Instead of one very fast centralized 
cluster of mainframes, we see thousands of servers spreading the workload
and achieving much the same results.  This has it's own challenges.  Managing
a few things is harder than managing thousands of things. 

-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#91114

On 05/22/2015 11:11 PM, amber wrote:
> «»
> 
> On 22/05/2015 21:40, Tim Daneliuk wrote:
>>    https://www.tundraware.com/TechnicalNotes/Python-Is-Middleware/
> Quoting that article
> «And no, you couldn't get a C based OS to do what TPF does even if you
> did have a couple hundred million dollars to redo it, »
> 
> Why couldn't a C based OS do what TPF does?
> 
> My understanding is that if the programming language is Turing-Complete,
> it can do anything that any other Turing-Complete language can do.  And
> that assembler is a Turing-Complete language.
> 
> jonathon
> 
> 
> 
> 


C could - in principle - do it.  As you point out, both are Turing Complete.
But, "in principle" is quite different than "in actual fact".  At the time
that article was written almost 15 years ago, the TPF systems in use
were running applications written in hand optimized assembly language on the
largest mainframes money could buy.  Everything about that environment was
optimized for speed - from partially populating disk surfaces to running the
thinnest possible operating system executive.  (In those days, TPF itself didn't 
even have memory protection, or at least, it was just being added as an OS
feature.)

The point is that it would have been nearly impossible technically to
rewrite all that in C and expect the same level of minimal path length/
max throughput.  Give the sheer transaction load on those machines, this
would have been a showstopper.

But that was then and this is now.  These days, much of that capability 
HAS been written in higher level languages because of scale-out architectures
and messaging/queuing middleware.  Instead of one very fast centralized 
cluster of mainframes, we see thousands of servers spreading the workload
and achieving much the same results.  This has it's own challenges.  Managing
a few things is harder than managing thousands of things. 

-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#91095

Ian Kelly <ian.g.kelly@gmail.com> writes:

> On Fri, May 22, 2015 at 9:31 PM, Michael Torrie <torriem@gmail.com> wrote:
> > On 05/22/2015 07:54 PM, Terry Reedy wrote:
> >> On 5/22/2015 5:40 PM, Tim Daneliuk wrote:
> >>
> >>> Lo these many years ago, I argued that Python is a whole lot more than
> >>> a programming language:
> >>>
> >>>     https://www.tundraware.com/TechnicalNotes/Python-Is-Middleware/
> >>
> >> Perhaps something at tundraware needs updating.
> >> '''
> >> This Connection is Untrusted
> >>
> >> You have asked Firefox to connect securely to www.tundraware.com, but we
> >> can't confirm that your connection is secure.
> >> […]

> Without some prior reason to trust the certificate, the certificate is
> meaningless. How is the browser to distinguish between a legitimate
> self-signed cert and a self-signed cert presented by an attacker
> conducting a man-in-the-middle attack?

Any unencrypted HTTP (“http://…”) connection has the same problem. Yet
the same browsers don't present a big scary warning for those?

The flaw in the browser is that it doesn't complain when an unencrypted
HTTP connection is established, but only complains when an *encrypted*
connection is made to a site with a self-signed certificate.

> There is still some value in TLS with a self-signed certificate in
> that at least the connection is encrypted and can't be eavesdropped by
> an attacker who can only read the channel, but there is no assurance
> that the party you're communicating with actually owns the public key
> that you've been presented.

Right. By that logic, let's advocate for browsers to present a big
intrusive warning for every HTTP connection that has no SSL layer or
certificate.

I will agree that a self-signed certificate presents the problem of how
to verify the certificate automatically.

Where I disagree is that this is somehow less secure than a completely
*unencrypted* HTTP connection. No, the opposite is true.

-- 
 \     “DRM doesn't inconvenience [lawbreakers] — indeed, over time it |
  `\     trains law-abiding users to become [lawbreakers] out of sheer |
_o__)                        frustration.” —Charles Stross, 2010-05-09 |
Ben Finney

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

#91096

On 05/22/2015 10:10 PM, Ian Kelly wrote:
> On Fri, May 22, 2015 at 9:31 PM, Michael Torrie <torriem@gmail.com> wrote:
>> On 05/22/2015 07:54 PM, Terry Reedy wrote:
>>> On 5/22/2015 5:40 PM, Tim Daneliuk wrote:
>>>
>>>> Lo these many years ago, I argued that Python is a whole lot more than
>>>> a programming language:
>>>>
>>>>     https://www.tundraware.com/TechnicalNotes/Python-Is-Middleware/
>>>
>>> Perhaps something at tundraware needs updating.
>>> '''
>>> This Connection is Untrusted
>>>
>>> You have asked Firefox to connect securely to www.tundraware.com, but we
>>> can't confirm that your connection is secure.
>>>
>>> Normally, when you try to connect securely, sites will present trusted
>>> identification to prove that you are going to the right place. However,
>>> this site's identity can't be verified.
>>> '''
>>
>> Sigh. I blame this as much on the browser.  There's no inherent reason
>> why a connection to a site secured with a self-signed certificate is
>> insecure.  In fact it's definitely not.
> 
> Sure it is. Without some prior reason to trust the certificate, the
> certificate is meaningless. How is the browser to distinguish between
> a legitimate self-signed cert and a self-signed cert presented by an
> attacker conducting a man-in-the-middle attack?

How does a CA actually help this problem?  It just puts trust in some
third party. But as we know, CA authorities are not all trustworthy and
they certainly don't guarantee that the site is what it says it is.  A
valid SSL cert does not mean the site won't try to hack your browser or
steal your identity.  The current system lulls us into a false sense of
security.  A self-signed cert is perfectly secure if you can verify the
fingerprint with the site's owner.  Granted that process is the rub.

> There is still some value in TLS with a self-signed certificate in 
> that at least the connection is encrypted and can't be eavesdropped
> by an attacker who can only read the channel, but there is no
> assurance that the party you're communicating with actually owns the
> public key that you've been presented.

The same can be said of CA-signed certificates.  The only way to know if
the site is who they say they are is to know what the cert's fingerprint
ought to be and see if it still is. I used to use a firefox plugin for
this purpose, but certs for some major sites like even www.google.com
change with such frequency that the utility of the plugin went away.

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

#91110

On 2015-05-23, Michael Torrie <torriem@gmail.com> wrote:
> On 05/22/2015 10:10 PM, Ian Kelly wrote:
>> There is still some value in TLS with a self-signed certificate in 
>> that at least the connection is encrypted and can't be eavesdropped
>> by an attacker who can only read the channel, but there is no
>> assurance that the party you're communicating with actually owns the
>> public key that you've been presented.
>
> The same can be said of CA-signed certificates.

I think you are falling into the trap of believing that all things are
either perfect or they are worthless. CAs aren't perfect, but neither
are they worthless. A self-signed certificate, however, is worthless.

> The only way to know if the site is who they say they are is to know
> what the cert's fingerprint ought to be and see if it still is. I
> used to use a firefox plugin for this purpose, but certs for some
> major sites like even www.google.com change with such frequency that
> the utility of the plugin went away.

http://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

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

#91118

On 2015-05-23 11:10, Jon Ribbens wrote:
> On 2015-05-23, Michael Torrie <torriem@gmail.com> wrote:
> > The same can be said of CA-signed certificates.
> 
> I think you are falling into the trap of believing that all things
> are either perfect or they are worthless. CAs aren't perfect, but
> neither are they worthless. A self-signed certificate, however, is
> worthless.

A self-signed certificate may be of minimal worth the *first* time you
visit a site, but if you return to the site, that initial
certificate's signature can be used to confirm that you're talking to
the same site you talked to previously.  This is particularly
valuable on a laptop where you make initial contact over a (I
hesitate to say "more secure") less hostile connection through your
home ISP.  Then, when you're out at the library, coffee-shop, or some
hacker convention on their wifi, it's possible to determine whether
you're securely connecting to the *same* site, or whether an attempt
is being made to MitM because the cert changed.

-tkc

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

#91119

On Sat, May 23, 2015 at 9:34 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> A self-signed certificate may be of minimal worth the *first* time you
> visit a site, but if you return to the site, that initial
> certificate's signature can be used to confirm that you're talking to
> the same site you talked to previously.  This is particularly
> valuable on a laptop where you make initial contact over a (I
> hesitate to say "more secure") less hostile connection through your
> home ISP.  Then, when you're out at the library, coffee-shop, or some
> hacker convention on their wifi, it's possible to determine whether
> you're securely connecting to the *same* site, or whether an attempt
> is being made to MitM because the cert changed.

You can get the exact same benefit (knowing when the cert changes)
with an externally-signed cert too. How many people actually bother to
check?

ChrisA

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

#91156

On 05/23/2015 05:40 AM, Chris Angelico wrote:
> On Sat, May 23, 2015 at 9:34 PM, Tim Chase
> <python.list@tim.thechases.com> wrote:
>> A self-signed certificate may be of minimal worth the *first* time you
>> visit a site, but if you return to the site, that initial
>> certificate's signature can be used to confirm that you're talking to
>> the same site you talked to previously.  This is particularly
>> valuable on a laptop where you make initial contact over a (I
>> hesitate to say "more secure") less hostile connection through your
>> home ISP.  Then, when you're out at the library, coffee-shop, or some
>> hacker convention on their wifi, it's possible to determine whether
>> you're securely connecting to the *same* site, or whether an attempt
>> is being made to MitM because the cert changed.
> 
> You can get the exact same benefit (knowing when the cert changes)
> with an externally-signed cert too. How many people actually bother to
> check?

Except that you won't be notified automatically.  A MitM attack nowadays
most often uses a valid certificate signed by a recognized (though
untrustworthy) CA.  Thus with a self-signed cert that you've previously
accepted, you'll immediate know of the MitM attack.  The odds of this
happening inside China, for example, is very high.  Wasn't that long ago
bogus google certificates (still valid) were found in the wild.
Eventually Firefox and Chrome revoked the CA cert, but only after it was
found out.

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

#91162

On Sat, May 23, 2015 at 8:57 PM, Michael Torrie <torriem@gmail.com> wrote:
> On 05/23/2015 05:40 AM, Chris Angelico wrote:
>> On Sat, May 23, 2015 at 9:34 PM, Tim Chase
>> <python.list@tim.thechases.com> wrote:
>>> A self-signed certificate may be of minimal worth the *first* time you
>>> visit a site, but if you return to the site, that initial
>>> certificate's signature can be used to confirm that you're talking to
>>> the same site you talked to previously.  This is particularly
>>> valuable on a laptop where you make initial contact over a (I
>>> hesitate to say "more secure") less hostile connection through your
>>> home ISP.  Then, when you're out at the library, coffee-shop, or some
>>> hacker convention on their wifi, it's possible to determine whether
>>> you're securely connecting to the *same* site, or whether an attempt
>>> is being made to MitM because the cert changed.
>>
>> You can get the exact same benefit (knowing when the cert changes)
>> with an externally-signed cert too. How many people actually bother to
>> check?
>
> Except that you won't be notified automatically.  A MitM attack nowadays
> most often uses a valid certificate signed by a recognized (though
> untrustworthy) CA.  Thus with a self-signed cert that you've previously
> accepted, you'll immediate know of the MitM attack.

I fail to see how this is the case. If a new certificate is suddenly
provided, why should the status of the *previous* certificate have
anything to do with whether the browser automatically notifies you? A
change from a self-signed certificate to a CA certificate likely just
means that the site has upgraded its certificate, not that a MitM
attack is underway.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web