date:20111028


On 2011-10-29 3:46 PM, Olaf TNSB wrote:

Shawn,

I'm not sure that I could be as relaxed about self signed certs as you. It
feels a lot like when I download code with a gpg/pgp signature where the
signing key hasn't been signed by anyone...


Do you feel much worse about code with gpg signature that whose key is 
not connected to any web of trust, than code that is unsigned?


Actually an unsigned code signing key is just as good as one connected 
to the web of trust, since the main thing that is useful to know is that 
version 1.7 is issued by the same people as version 1.6.

___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

2011-10-28 Thread Olaf TNSB

Shawn,

I'm not sure that I could be as relaxed about self signed certs as you. It
feels a lot like when I download code with a gpg/pgp signature where the
signing key hasn't been signed by anyone...

I think the web of trust idea is probably the solution for SSL certs, but I
may be wrong.  :P

However, saying that, I found the following article from the EFF useful...

https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack

I'm using Certificate Patrol (mentioned). I don't know that it makes me any
safer, but I sure as hell feel more aware of the huge # of cert replacements
that occur in my daily net usage.

Cheers,

Olaf

P.S. Apologies about the TOFU. I'm still learning my phone's email app.
On 29/10/2011 5:05 AM, "Shawn Willden"  wrote:

> OT:  Does anyone else think it's crazy that web browsers flash huge red
> warning signs when they see a self-signed cert, as though that's a clear
> indication of some sort of attack being attempted, which is almost never the
> case?
>
> It's always seemed to me than an appropriate browser response to a
> self-signed cert is to accept it and use it to establish an encrypted
> session, but not to display the lock icon or anything else that would make
> the user think this page is especially secure.  For bonus points, browsers
> could implement ssh-style notification of server key changes.
>
> But the sort of big scary warnings browsers now display makes no sense to
> me.
>
> On Fri, Oct 28, 2011 at 10:22 AM, Brian Warner  wrote:
>
>> The tahoe-lafs.org server has moved! But, we had a hiccup with the SSL
>> certificate on the new server. While Zooko gets a new one generated and
>> installed, there is a self-signed certificate in place. So don't be
>> surprised if you see the "OMG SELF-SIGNED CERT NOO!" warning (known as
>> the "Larry Dialog" in firefox). It should be fixed within a couple of
>> hours, so don't feel obligated to bypass the warning.. just check back
>> in later.
>>
>> migration!
>>  -Brian
>> ___
>> tahoe-dev mailing list
>> tahoe-dev@tahoe-lafs.org
>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>
>
>
>
> --
> Shawn
>
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] 1.9 update: soon! Need help with PyCrypto-2.4!


On 2011-10-29 6:01 AM, Shawn Willden wrote:

Are there any well-written crypto libraries, in any language?  Having spent
a frightful amount of time trudging through openssl lately as well as a
couple of Java crypto libs (Cryptix and Bouncy Castle) I've begun thinking
that the intersection between the set of people who write non-toy crypto
libraries and the set of people who write tight, clean, well-structured code
may be empty.


A long time ago, I dug my way through Crypto++ to extract the code that 
actually did the encryption and put it in a different context.  Seemed 
pretty good to me - but then I am a fan of massive templating, which not 
everyone is.


___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL wolves attack migration squirrels, film at 11

2011-10-28 Thread Zooko O'Whielacronx

Folks: I tried to enable non-HTTPS mode on the new web server, but
apparently I've failed. Perhaps that's because my web browser
remembers the Strict-Transport-Security header that the server earlier
distributed and it knows never to talk non-HTTPS mode to this server
again. :-)

Meanwhile I asked my Certificate Authority to sign a new pubkey (since
I appear to have accidentally deleted the server's previous priv key),
but they haven't gotten back to me yet.

Anyway, if you can connect over HTTP or if you click through the scary
warnings about a self-signed certificate, then please by all means do
your worst to the shiny new "http://tahoe-lafs.org";. It is *supposed*
to look just like the old one, but it is supposed to be faster and
more stable. If you find anything missing or wrong, or if you think
some of the operations still seem sluggish, please let me know as soon
as possible so I can fix it while I still have the old server to copy
files from and to serve as a model.

Thanks!

Forward to ninja victory!

--Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

On 2011-10-29 4:21 AM, Kevin Reid wrote:

On Oct 28, 2011, at 14:05, Shawn Willden wrote:

OT:  Does anyone else think it's crazy that web browsers flash huge red warning 
signs when they see a self-signed cert, as though that's a clear indication of 
some sort of attack being attempted, which is almost never the case?

It's always seemed to me than an appropriate browser response to a self-signed 
cert is to accept it and use it to establish an encrypted session, but not to 
display the lock icon or anything else that would make the user think this page 
is especially secure.  For bonus points, browsers could implement ssh-style 
notification of server key changes.

But the sort of big scary warnings browsers now display makes no sense to me.

I don't know what the browser vendors are thinking, but I can make some stuff 
up.

Argument #1:

   Premise 1: "https:" means it's secure, to the user.

   Premise 2: HTTPS security rests on the CAs providing certificates
  for DNS names.

   Conclusion: If a certificate is not signed-by-a-CA-etc. then the user
   thinks they are secure but aren't; therefore warn them.

Not showing indicators of security to the user solves this problem, but if you hide 
"https:" then you're not accurately displaying the URL...

Show https, but show the name on the certificate and the padlock icon 
if, and only if, the certificate is signed by a CA.

Argument #2:

   If the author of a *link* wrote "https:" then they expect that link
   to securely designate the intended target; if there is a certificate
   problem then the link is not succeeding at that job and proceeding
   despite that would be a vulnerability.

>
> For this concern, changing the UI doesn't help: the only thing that
> would be better than trustworthy CAs would be including key
> fingerprints in the links.

Exactly so.  We need the ability to include key fingerprints in the links.

Allow the author of the link to designate the hash of the certificate 
root.  http://example.com, 
root="p4XzhuKAp/fp7Jbu18VHmf5Qod6twbgKCsLGgJe3hr">

This prevents state level attacks.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11


On 2011-10-29 4:05 AM, Shawn Willden wrote:

OT:  Does anyone else think it's crazy that web browsers flash huge red
warning signs when they see a self-signed cert, as though that's a clear
indication of some sort of attack being attempted, which is almost never the
case?

It's always seemed to me than an appropriate browser response to a
self-signed cert is to accept it and use it to establish an encrypted
session, but not to display the lock icon or anything else that would make
the user think this page is especially secure.  For bonus points, browsers
could implement ssh-style notification of server key changes.


Well of course, but CA's don't want people providing their own 
certificate, even though in practice self signed certificates provide 
almost the same level of security as CA certificates, and certificates 
with ssh-style notification of server key root changes provide a good 
deal more security (ssl providing no security whatever against state 
level and similarly powerful adversaries, and limited security against 
less powerful adversaries, that is to say, no security whatever against 
anyone able to hack any one of a thousand or so CAs)


___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] dropping python2.4 support in 1.9?

2011-10-28 Thread Dudumomo

Just my feedback, several people and I, are using the SFTP solution (as, to
be honest, i don't like using the web interface) and we are even
recommending to do so.

Anyway, great job !!
On Oct 29, 2011 8:15 AM, "Brian Warner"  wrote:

> On 10/28/11 12:02 PM, Zooko O'Whielacronx wrote:
>
> > Short term solution: declare that Tahoe-LAFS v1.9 doesn't support
> > Python 2.4 anymore.
>
> I'm ok with that. The oldest Ubuntu LTS (8.04 Hardy, supported until
> April 2013) has python-2.5.2, after which the oldest (10.04 Lucid) will
> have python-2.6.5 until April 2015. The oldest supported Debian release
> (lenny) has 2.5.2, and current (squeeze) has 2.6.6 . Previous OS-X (10.6
> Snow Leopard) has 2.6.1, and 10.7 Lion reportedly has 2.7.1 . I'm
> guessing other OSes are following roughly the same schedule.
>
> In practical terms, does this mean we should just shut down the CentOS5
> buildslave?
>
> > If anybody is dying to use Tahoe-LAFS v1.9 with Python 2.4, speak up
> > now!
>
> Yeah! Unless there's a sudden clamor of support for py2.4, I'm dropping
> it from 1.9.
>
> There are a handful of things we can improve once we've properly
> abandoned py2.4, but of course those will wait until after 1.9.
>
> > Possible long-term solution: replace the place where Twisted depends
> > on PyCrypto with a dependency on something else
>
> I'd also like to consider moving SFTP to a plugin (which first entails
> creating a plugin system). I'd like to hear folks opinions, but I've got
> the general feeling that SFTP is used relatively rarely, compared to the
> webapi.
>
> cheers,
>  -Brian
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] dropping python2.4 support in 1.9?

2011-10-28 Thread Zooko O'Whielacronx

On Fri, Oct 28, 2011 at 6:14 PM, Brian Warner  wrote:
>
> In practical terms, does this mean we should just shut down the CentOS5
> buildslave?

Well, let's ask the maintainer of the CentOS5 buildslave what he would
do if he wanted to run Tahoe-LAFS on CentOS5.

Dear FreeStorm:

Would you

a. Upgrade to a newer CentOS release,

b. Install a newer Python on your CentOS5,

c. Contribute patches to PyCrypto so that it can build with Python 2.4?

:-)

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] dropping python2.4 support in 1.9?

On 10/28/11 12:02 PM, Zooko O'Whielacronx wrote:

> Short term solution: declare that Tahoe-LAFS v1.9 doesn't support
> Python 2.4 anymore.

I'm ok with that. The oldest Ubuntu LTS (8.04 Hardy, supported until
April 2013) has python-2.5.2, after which the oldest (10.04 Lucid) will
have python-2.6.5 until April 2015. The oldest supported Debian release
(lenny) has 2.5.2, and current (squeeze) has 2.6.6 . Previous OS-X (10.6
Snow Leopard) has 2.6.1, and 10.7 Lion reportedly has 2.7.1 . I'm
guessing other OSes are following roughly the same schedule.

In practical terms, does this mean we should just shut down the CentOS5
buildslave?

> If anybody is dying to use Tahoe-LAFS v1.9 with Python 2.4, speak up
> now!

Yeah! Unless there's a sudden clamor of support for py2.4, I'm dropping
it from 1.9.

There are a handful of things we can improve once we've properly
abandoned py2.4, but of course those will wait until after 1.9.

> Possible long-term solution: replace the place where Twisted depends
> on PyCrypto with a dependency on something else

I'd also like to consider moving SFTP to a plugin (which first entails
creating a plugin system). I'd like to hear folks opinions, but I've got
the general feeling that SFTP is used relatively rarely, compared to the
webapi.

cheers,
 -Brian
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

How do you have a false sense of security if the browser displays the two
bottom levels exactly the same, as in, the user has no way to tell the
difference without digging into page info?

Note what I already mentioned about Firefox -- you can't "look for https"
because it's not even displayed.  What you should look for is the lock icon,
which clearly should not be displayed for self-signed certs.

On Fri, Oct 28, 2011 at 2:03 PM, Randall Mason wrote:

> most - Encrypted and authenticated
> least - Encrypted and unauthenticated
> middle - Unencrypted and unauthenticated
>
> I would say that a false sense of security is worse than a real sense of
> insecurity.  Most people are black and white thinkers and if they are
> constantly told "look for https", you give them a false sense of security.
>  On Oct 28, 2011 10:48 PM, "Shawn Willden"  wrote:
>
>> Yes, yes, but that doesn't explain why browsers treat encrypted but
>> unauthenticated connections as *less* secure that connections that are
>> unencrypted *and* unauthenticated.
>>
>> If you were asked to rank the security of the following:
>>
>> Encrypted and authenticated
>> Encrypted and unauthenticated
>> Unencrypted and unauthenticated
>>
>> How would you order them?  How do browsers order them?
>>
>> On Fri, Oct 28, 2011 at 1:19 PM, Randall Mason 
>> wrote:
>>
>>> So the key to this discussion is that https provides two things.  First
>>> is encryption.  That my data is only seen by me and the server I'm talking
>>> to.  This is the part that you two are talking about.  The second thing that
>>> it does is provide identity.  That I not only know that only the person I'm
>>> talking to is the server, but also who owns and controls the server.  This
>>> is the part that browsers are warning you about.  I don't care as much about
>>> encrypting my credit card as who can decrypt that information.  With self
>>> signed certs, you need some sort of web of trust.
>>> On Oct 28, 2011 9:40 PM, "Shawn Willden"  wrote:
>>>
 On Fri, Oct 28, 2011 at 12:21 PM, Kevin Reid wrote:

> I don't know what the browser vendors are thinking, but I can make some
> stuff up.
>

 That's always my approach when I don't know the answer :-)


> Argument #1:
>
>  Premise 1: "https:" means it's secure, to the user.
>
>  Premise 2: HTTPS security rests on the CAs providing certificates
> for DNS names.
>
>  Conclusion: If a certificate is not signed-by-a-CA-etc. then the user
>  thinks they are secure but aren't; therefore warn them.
>
> Not showing indicators of security to the user solves this problem, but
> if you hide "https:" then you're not accurately displaying the URL...
>

 I don't think "accurately displaying the URL" is important.  In the last
 few years browsers have started altering displayed URLs in all sorts of
 ways, including dropping the protocol prefix entirely in many cases.  I 
 just
 checked and neither Firefox nor Google Chrome display http://.
  Further, while Chrome does display https:// on SSL-enabled sites (and
 highlight it in green), FF doesn't display https:// either.

 Displaying the URL accurately isn't relevant to 95% (99%?) of users of
 the web.  The remainder can always figure out what they need to.


> Argument #2:
>
>  If the author of a *link* wrote "https:" then they expect that link
>  to securely designate the intended target; if there is a certificate
>  problem then the link is not succeeding at that job and proceeding
>  despite that would be a vulnerability.


 Among all the ways a misconfigured web server could cause problems, I
 think this is pretty low on the list.

 --
 Shawn

 ___
 tahoe-dev mailing list
 tahoe-dev@tahoe-lafs.org
 http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev


>>> ___
>>> tahoe-dev mailing list
>>> tahoe-dev@tahoe-lafs.org
>>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>>
>>>
>>
>>
>> --
>> Shawn
>>
>> ___
>> tahoe-dev mailing list
>> tahoe-dev@tahoe-lafs.org
>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>
>>
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>


-- 
Shawn
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

2011-10-28 Thread Randall Mason

most - Encrypted and authenticated
least - Encrypted and unauthenticated
middle - Unencrypted and unauthenticated

I would say that a false sense of security is worse than a real sense of
insecurity.  Most people are black and white thinkers and if they are
constantly told "look for https", you give them a false sense of security.
 On Oct 28, 2011 10:48 PM, "Shawn Willden"  wrote:

> Yes, yes, but that doesn't explain why browsers treat encrypted but
> unauthenticated connections as *less* secure that connections that are
> unencrypted *and* unauthenticated.
>
> If you were asked to rank the security of the following:
>
> Encrypted and authenticated
> Encrypted and unauthenticated
> Unencrypted and unauthenticated
>
> How would you order them?  How do browsers order them?
>
> On Fri, Oct 28, 2011 at 1:19 PM, Randall Mason wrote:
>
>> So the key to this discussion is that https provides two things.  First is
>> encryption.  That my data is only seen by me and the server I'm talking to.
>> This is the part that you two are talking about.  The second thing that it
>> does is provide identity.  That I not only know that only the person I'm
>> talking to is the server, but also who owns and controls the server.  This
>> is the part that browsers are warning you about.  I don't care as much about
>> encrypting my credit card as who can decrypt that information.  With self
>> signed certs, you need some sort of web of trust.
>> On Oct 28, 2011 9:40 PM, "Shawn Willden"  wrote:
>>
>>> On Fri, Oct 28, 2011 at 12:21 PM, Kevin Reid  wrote:
>>>
 I don't know what the browser vendors are thinking, but I can make some
 stuff up.

>>>
>>> That's always my approach when I don't know the answer :-)
>>>
>>>
 Argument #1:

  Premise 1: "https:" means it's secure, to the user.

  Premise 2: HTTPS security rests on the CAs providing certificates
 for DNS names.

  Conclusion: If a certificate is not signed-by-a-CA-etc. then the user
  thinks they are secure but aren't; therefore warn them.

 Not showing indicators of security to the user solves this problem, but
 if you hide "https:" then you're not accurately displaying the URL...

>>>
>>> I don't think "accurately displaying the URL" is important.  In the last
>>> few years browsers have started altering displayed URLs in all sorts of
>>> ways, including dropping the protocol prefix entirely in many cases.  I just
>>> checked and neither Firefox nor Google Chrome display http://.  Further,
>>> while Chrome does display https:// on SSL-enabled sites (and highlight
>>> it in green), FF doesn't display https:// either.
>>>
>>> Displaying the URL accurately isn't relevant to 95% (99%?) of users of
>>> the web.  The remainder can always figure out what they need to.
>>>
>>>
 Argument #2:

  If the author of a *link* wrote "https:" then they expect that link
  to securely designate the intended target; if there is a certificate
  problem then the link is not succeeding at that job and proceeding
  despite that would be a vulnerability.
>>>
>>>
>>> Among all the ways a misconfigured web server could cause problems, I
>>> think this is pretty low on the list.
>>>
>>> --
>>> Shawn
>>>
>>> ___
>>> tahoe-dev mailing list
>>> tahoe-dev@tahoe-lafs.org
>>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>>
>>>
>> ___
>> tahoe-dev mailing list
>> tahoe-dev@tahoe-lafs.org
>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>
>>
>
>
> --
> Shawn
>
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] 1.9 update: soon! Need help with PyCrypto-2.4!

On Fri, Oct 28, 2011 at 1:02 PM, Zooko O'Whielacronx wrote:

> I'm extremely annoyed at the fact that we depend on PyCrypto, which I
> regard as too sloppily-written to be secure

Are there any well-written crypto libraries, in any language?  Having spent
a frightful amount of time trudging through openssl lately as well as a
couple of Java crypto libs (Cryptix and Bouncy Castle) I've begun thinking
that the intersection between the set of people who write non-toy crypto
libraries and the set of people who write tight, clean, well-structured code
may be empty.

> (What does "be cautious" mean, anyway? I guess it means

feel worry in your heart but do it anyway.)
>

LOL! (literally; made my colleagues look over to see what was funny, and
when I shared, they LOL'ed too).

Another possible meaning is "consider this to be opportunistic security that
might help but might not, so don't do anything important with it."  Well,
unless you really have to and then you're back to worry in your heart.

Sorry for the content-free response.  My opinion is that dropping Python 2.4
support is fine, but I don't know much about the world of Python
deployments.

-- 
Shawn
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

Yes, yes, but that doesn't explain why browsers treat encrypted but
unauthenticated connections as *less* secure that connections that are
unencrypted *and* unauthenticated.

If you were asked to rank the security of the following:

Encrypted and authenticated
Encrypted and unauthenticated
Unencrypted and unauthenticated

How would you order them?  How do browsers order them?

On Fri, Oct 28, 2011 at 1:19 PM, Randall Mason wrote:

> So the key to this discussion is that https provides two things.  First is
> encryption.  That my data is only seen by me and the server I'm talking to.
> This is the part that you two are talking about.  The second thing that it
> does is provide identity.  That I not only know that only the person I'm
> talking to is the server, but also who owns and controls the server.  This
> is the part that browsers are warning you about.  I don't care as much about
> encrypting my credit card as who can decrypt that information.  With self
> signed certs, you need some sort of web of trust.
> On Oct 28, 2011 9:40 PM, "Shawn Willden"  wrote:
>
>> On Fri, Oct 28, 2011 at 12:21 PM, Kevin Reid  wrote:
>>
>>> I don't know what the browser vendors are thinking, but I can make some
>>> stuff up.
>>>
>>
>> That's always my approach when I don't know the answer :-)
>>
>>
>>> Argument #1:
>>>
>>>  Premise 1: "https:" means it's secure, to the user.
>>>
>>>  Premise 2: HTTPS security rests on the CAs providing certificates
>>> for DNS names.
>>>
>>>  Conclusion: If a certificate is not signed-by-a-CA-etc. then the user
>>>  thinks they are secure but aren't; therefore warn them.
>>>
>>> Not showing indicators of security to the user solves this problem, but
>>> if you hide "https:" then you're not accurately displaying the URL...
>>>
>>
>> I don't think "accurately displaying the URL" is important.  In the last
>> few years browsers have started altering displayed URLs in all sorts of
>> ways, including dropping the protocol prefix entirely in many cases.  I just
>> checked and neither Firefox nor Google Chrome display http://.  Further,
>> while Chrome does display https:// on SSL-enabled sites (and highlight it
>> in green), FF doesn't display https:// either.
>>
>> Displaying the URL accurately isn't relevant to 95% (99%?) of users of the
>> web.  The remainder can always figure out what they need to.
>>
>>
>>> Argument #2:
>>>
>>>  If the author of a *link* wrote "https:" then they expect that link
>>>  to securely designate the intended target; if there is a certificate
>>>  problem then the link is not succeeding at that job and proceeding
>>>  despite that would be a vulnerability.
>>
>>
>> Among all the ways a misconfigured web server could cause problems, I
>> think this is pretty low on the list.
>>
>> --
>> Shawn
>>
>> ___
>> tahoe-dev mailing list
>> tahoe-dev@tahoe-lafs.org
>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>
>>
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>


-- 
Shawn
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

2011-10-28 Thread Randall Mason

So the key to this discussion is that https provides two things.  First is
encryption.  That my data is only seen by me and the server I'm talking to.
This is the part that you two are talking about.  The second thing that it
does is provide identity.  That I not only know that only the person I'm
talking to is the server, but also who owns and controls the server.  This
is the part that browsers are warning you about.  I don't care as much about
encrypting my credit card as who can decrypt that information.  With self
signed certs, you need some sort of web of trust.
On Oct 28, 2011 9:40 PM, "Shawn Willden"  wrote:

> On Fri, Oct 28, 2011 at 12:21 PM, Kevin Reid  wrote:
>
>> I don't know what the browser vendors are thinking, but I can make some
>> stuff up.
>>
>
> That's always my approach when I don't know the answer :-)
>
>
>> Argument #1:
>>
>>  Premise 1: "https:" means it's secure, to the user.
>>
>>  Premise 2: HTTPS security rests on the CAs providing certificates
>> for DNS names.
>>
>>  Conclusion: If a certificate is not signed-by-a-CA-etc. then the user
>>  thinks they are secure but aren't; therefore warn them.
>>
>> Not showing indicators of security to the user solves this problem, but if
>> you hide "https:" then you're not accurately displaying the URL...
>>
>
> I don't think "accurately displaying the URL" is important.  In the last
> few years browsers have started altering displayed URLs in all sorts of
> ways, including dropping the protocol prefix entirely in many cases.  I just
> checked and neither Firefox nor Google Chrome display http://.  Further,
> while Chrome does display https:// on SSL-enabled sites (and highlight it
> in green), FF doesn't display https:// either.
>
> Displaying the URL accurately isn't relevant to 95% (99%?) of users of the
> web.  The remainder can always figure out what they need to.
>
>
>> Argument #2:
>>
>>  If the author of a *link* wrote "https:" then they expect that link
>>  to securely designate the intended target; if there is a certificate
>>  problem then the link is not succeeding at that job and proceeding
>>  despite that would be a vulnerability.
>
>
> Among all the ways a misconfigured web server could cause problems, I think
> this is pretty low on the list.
>
> --
> Shawn
>
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] 1.9 update: soon! Need help with PyCrypto-2.4!

2011-10-28 Thread Zooko O'Whielacronx

I'm extremely annoyed at the fact that we depend on PyCrypto, which I
regard as too sloppily-written to be secure, and also as too
sloppily-written to build and install on all the platforms we support.
For a while there the pain had lessened because there were no new
releases of PyCrypto, and people had worked-around all of the known
problems in the most recent release. But unfortunately they are
apparently maintaining PyCrypto again, so now it is going to resume
interfering with our work.

Short term solution: declare that Tahoe-LAFS v1.9 doesn't support
Python 2.4 anymore. (This is because this particular bug in PyCrypto
is probably specific to being it built for Python 2.4) I'm okay with
that, and it is a fast way to reduce our load, and I have a lot of
other things that I want to do (launch Least Authority Enterprises to
live customers, doc writing and auditing for Tahoe-LAFS v1.9,
preparing for the Summit, ...).

If anybody is dying to use Tahoe-LAFS v1.9 with Python 2.4, speak up now!

Possible long-term solution: replace the place where Twisted depends
on PyCrypto with a dependency on something else (pycryptopp, botan,
?). This is a lot of work, because there isn't a ready-made crypto
library for Python which does everything that Twisted wants from
PyCrypto. See Twisted ticket #4633.

Possible long-term solution: replace the place where Twisted depends
on PyCrypto with a null plugin that doesn't actually encrypt, and
replace the warning in
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/FTP-and-SFTP.rst#configuring-sftp-access
so that instead of saying "We don't trust the crypto on the SFTP
connection, so be cautious about it.", it says "There is no crypto on
the SFTP connection, so don't use it except over loopback or a secure
network.". (What does "be cautious" mean, anyway? I guess it means
feel worry in your heart but do it anyway.)

I'm not sure that would work, but I prefer giving people a thing that
claims to not have security over a thing that claims to have security
but that claim is suspect. :-(

Oh by the way, I think those docs are now obsolete -- they say there
are no AES timing defenses in the PyCrypto code, but I think they
might have added that. Not sure.

Impatiently yours,

Zooko

http://twistedmatrix.com/trac/ticket/4633# allow applications to
"bring their own crypto" to avoid the dependency of conch on PyCrypto
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

On Fri, Oct 28, 2011 at 12:21 PM, Kevin Reid  wrote:

> I don't know what the browser vendors are thinking, but I can make some
> stuff up.
>

That's always my approach when I don't know the answer :-)

> Argument #1:
>
>  Premise 1: "https:" means it's secure, to the user.
>
>  Premise 2: HTTPS security rests on the CAs providing certificates
> for DNS names.
>
>  Conclusion: If a certificate is not signed-by-a-CA-etc. then the user
>  thinks they are secure but aren't; therefore warn them.
>
> Not showing indicators of security to the user solves this problem, but if
> you hide "https:" then you're not accurately displaying the URL...
>

I don't think "accurately displaying the URL" is important.  In the last few
years browsers have started altering displayed URLs in all sorts of ways,
including dropping the protocol prefix entirely in many cases.  I just
checked and neither Firefox nor Google Chrome display http://.  Further,
while Chrome does display https:// on SSL-enabled sites (and highlight it in
green), FF doesn't display https:// either.

Displaying the URL accurately isn't relevant to 95% (99%?) of users of the
web.  The remainder can always figure out what they need to.

> Argument #2:
>
>  If the author of a *link* wrote "https:" then they expect that link
>  to securely designate the intended target; if there is a certificate
>  problem then the link is not succeeding at that job and proceeding
>  despite that would be a vulnerability.

Among all the ways a misconfigured web server could cause problems, I think
this is pretty low on the list.

-- 
Shawn
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

2011-10-28 Thread Dirk Loss

On 28.10.11 20:05, Shawn Willden wrote:
> OT:  Does anyone else think it's crazy that web browsers flash huge red
> warning signs when they see a self-signed cert, as though that's a clear
> indication of some sort of attack being attempted, which is almost never the
> case?

Peter Gutmann seems to completely agree with you in the "Indicating
Security Condition" chapter of his excellent "Engineering Security" book
(page 365 of the current draft).

http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf

Best regards,
Dirk
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

2011-10-28 Thread Kevin Reid

On Oct 28, 2011, at 14:05, Shawn Willden wrote:

> OT:  Does anyone else think it's crazy that web browsers flash huge red 
> warning signs when they see a self-signed cert, as though that's a clear 
> indication of some sort of attack being attempted, which is almost never the 
> case?
> 
> It's always seemed to me than an appropriate browser response to a 
> self-signed cert is to accept it and use it to establish an encrypted 
> session, but not to display the lock icon or anything else that would make 
> the user think this page is especially secure.  For bonus points, browsers 
> could implement ssh-style notification of server key changes.
> 
> But the sort of big scary warnings browsers now display makes no sense to me.

I don't know what the browser vendors are thinking, but I can make some stuff 
up.

Argument #1:

  Premise 1: "https:" means it's secure, to the user.

  Premise 2: HTTPS security rests on the CAs providing certificates
 for DNS names.

  Conclusion: If a certificate is not signed-by-a-CA-etc. then the user
  thinks they are secure but aren't; therefore warn them.

Not showing indicators of security to the user solves this problem, but if you 
hide "https:" then you're not accurately displaying the URL...

Argument #2:

  If the author of a *link* wrote "https:" then they expect that link
  to securely designate the intended target; if there is a certificate
  problem then the link is not succeeding at that job and proceeding
  despite that would be a vulnerability.

For this concern, changing the UI doesn't help: the only thing that would be 
better than trustworthy CAs would be including key fingerprints in the links.

-- 
Kevin Reid  

___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] SSL samurai attack migration ninjas, film at 11

OT:  Does anyone else think it's crazy that web browsers flash huge red
warning signs when they see a self-signed cert, as though that's a clear
indication of some sort of attack being attempted, which is almost never the
case?

It's always seemed to me than an appropriate browser response to a
self-signed cert is to accept it and use it to establish an encrypted
session, but not to display the lock icon or anything else that would make
the user think this page is especially secure.  For bonus points, browsers
could implement ssh-style notification of server key changes.

But the sort of big scary warnings browsers now display makes no sense to
me.

On Fri, Oct 28, 2011 at 10:22 AM, Brian Warner  wrote:

> The tahoe-lafs.org server has moved! But, we had a hiccup with the SSL
> certificate on the new server. While Zooko gets a new one generated and
> installed, there is a self-signed certificate in place. So don't be
> surprised if you see the "OMG SELF-SIGNED CERT NOO!" warning (known as
> the "Larry Dialog" in firefox). It should be fixed within a couple of
> hours, so don't feel obligated to bypass the warning.. just check back
> in later.
>
> migration!
>  -Brian
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>

-- 
Shawn
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] SSL samurai attack migration ninjas, film at 11

The tahoe-lafs.org server has moved! But, we had a hiccup with the SSL
certificate on the new server. While Zooko gets a new one generated and
installed, there is a self-signed certificate in place. So don't be
surprised if you see the "OMG SELF-SIGNED CERT NOO!" warning (known as
the "Larry Dialog" in firefox). It should be fixed within a couple of
hours, so don't feel obligated to bypass the warning.. just check back
in later.

migration!
 -Brian
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] 1.9 update: soon! Need help with PyCrypto-2.4!


I'd love to release 1.9 this weekend. I've given up on most of the
lingering docs tickets. I have some more manual testing to do (in
particular updating the "tahoe-deps" tarball and testing against it),
but we're pretty close.

One problem that surfaced, which I need someone to investigate:
FreeStorm's CentOS build failed last monday, probably because
PyCrypto-2.4 was released last week, and the buildslave seems to have
had problems compiling it:

 
http://tahoe-lafs.org/buildbot/builders/FreeStorm%20CentOS5-i386/builds/551/steps/build/logs/stdio

The last few lines are:

  creating build/lib.linux-i686-2.4/Crypto/Protocol
  copying lib/Crypto/Protocol/Chaffing.py ->
build/lib.linux-i686-2.4/Crypto/Protocol
  copying lib/Crypto/Protocol/AllOrNothing.py ->
build/lib.linux-i686-2.4/Crypto/Protocol
  copying lib/Crypto/Protocol/__init__.py ->
build/lib.linux-i686-2.4/Crypto/Protocol
  creating build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/_DSA.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/RSA.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/_RSA.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/ElGamal.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/DSA.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/_slowmath.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/pubkey.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/qNEW.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  copying lib/Crypto/PublicKey/__init__.py ->
build/lib.linux-i686-2.4/Crypto/PublicKey
  running build_ext
  error: Setup script exited with error: src/config.h: No such file or
directory


Can someone look into this? It might be trivial, or something wrong with
the buildslave, but I'd like to know that current tahoe trunk will
correctly download+compile PyCrypto-2.4 .

thanks!
 -Brian
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] server-migration ninjas strike the buildbot!