

Adam Langley's Pond: Secure Async Messaging - tptacek
https://pond.imperialviolet.org/

======
carbocation
> "Pond seeks to prevent leaking traffic information against everyone except a
> global passive attacker."

My favorite line in the article. It's a nice nod to the fact that this
Achilles heel is an issue that he is aware of / takes seriously.

~~~
lmgftp
Contrasted with the "forward":

    
    
       |Note: recent events have lead to these topics being in the news quite often in recent weeks. However, Pond is not a reaction to those events - it was started nearly a year ago.
    

Traffic information, of course, isn't the whole conversation, so his wit is
appreciated to make light air of the situation, but at the same time he's
quite serious about this little project. I'm impressed that it compiles at all
on my Arch machine, after his warning to Arch users.

On topic to your comment, unfortunately there's no way to avoid leaking
traffic information, or at least the fact that there is traffic at all, to a
"global passive attacker" :) gone are the days of radio silence

~~~
kragen
There's a paper from the 1990s
([https://gnunet.org/sites/default/files/10.1.1.43.4892.pdf](https://gnunet.org/sites/default/files/10.1.1.43.4892.pdf)
I think, Pfitzmann 1991) on building an ISDN MIX for anonymous real-time voice
traffic. ISDN gives you two 56kbps or 64kbps channels in each direction for
voice, which you can connect to whoever you want. So you just keep these
channels open to somebody all the time and keep them full of data, even if
it's nonsense. Using fully isochronous streams in this way, assuming a fully
connected directed graph, which is overwhelmingly probable, it's impossible
for a global passive attacker to determine anything at all about who is
actually talking to whom, or how much; the traffic pattern simply is not
affected by the communication graph.

A thing I don't know is whether Pfitzmann et al.'s scheme held up to
subsequent analysis. I haven't even read the whole paper, actually.

------
andrewcooke
_(Or, how to better organise a discreet relationship with the Director of the
CIA.)_ from [https://github.com/agl/pond](https://github.com/agl/pond) (the
source) is a good elevator pitch, for people (like me) who are taking their
time getting what this is.

also, is code like this
[https://github.com/agl/pond/blob/master/server/server.go#L15...](https://github.com/agl/pond/blob/master/server/server.go#L153)
just extreme defensive programming? or is there some other reason for the
check (eg is not everything locked)?

also, does _2\. A GPA can learn when messages are sent to a non-home server
and which server that is._ get weaker if there are many users?

and why is it so quiet here? am i asking dumb questions? i've been deleting
the ones i work out answers to!

~~~
agwa
> also, is code like this
> [https://github.com/agl/pond/blob/master/server/server.go#L15...](https://github.com/agl/pond/blob/master/server/server.go#L153)
> just extreme defensive programming? or is there some other reason for the
> check (eg is not everything locked)?

That's checking for integer overflow - an often-overlooked source of many
security vulnerabilities.

That's a signed integer though, and I don't know if signed integer overflow
has defined behavior in Go. In C that would be undefined behavior, allowing
the compiler to do potentially nutty things, so you would want to do the
overflow check before the increment. (Edit: considering who the author of this
code is, I would assume that Go has sane defined behavior on signed integer
overflow ;-)

~~~
packetslave
From the Go language spec:

"For signed integers, the operations +, -, *, and << may legally overflow and
the resulting value exists and is deterministically defined by the signed
integer representation, the operation, and its operands. No exception is
raised as a result of overflow. A compiler may not optimize code under the
assumption that overflow does not occur. For instance, it may not assume that
x < x + 1 is always true."

    
    
      func main() {
        var foo int8 = 127
        fmt.Println(foo + 1)
      }
    

prints -128

~~~
agwa
Cool, thanks for the info!

Looking at the spec, I see that signed integers are elsewhere defined to be
represented using 2's complement, so this is completely kosher.

------
losvedir
> _For secure, synchronous communication we have OTR and, when run over Tor,
> this is pretty good. But while we have secure asynchronous messaging in the
> form of PGP email, it 's not forward secure and it gratuitously leaks
> traffic information._

This is probably a stupid question, but what exactly is the distinction here?
Why can't we just think of the "asynchronous messaging" email-equivalent as
long, drawn-out synchronous OTR communication?

~~~
johntb86
Can you send a message to someone who's currently offline using OTR? It seems
to use diffie helman, so I'd expect not.

~~~
chongli
That's an implementation detail. You could pack the handshake into automated
email messages handled by a proper client. Obviously this would not work with
any old client since you're effectively layering another protocol on top of
email.

------
diaz
I don't know about you people but I can't access this site in latest firefox:

    
    
      Secure Connection Failed
    
              An error occurred during a connection to pond.imperialviolet.org.
    
      Peer attempted old style (potentially vulnerable) handshake.
    
      (Error code: ssl_error_unsafe_negotiation)
    
      The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
      Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.

~~~
agwa
This is kind of ironic considering it's Adam Langley's website, but it appears
his server is not indicating that it supports secure renegotiation, and
apparently in the latest Firefox that's grounds to refuse a connection[1].
See:

[https://www.ssllabs.com/ssltest/analyze.html?d=pond.imperial...](https://www.ssllabs.com/ssltest/analyze.html?d=pond.imperialviolet.org)

[https://wiki.mozilla.org/Security:Renegotiation](https://wiki.mozilla.org/Security:Renegotiation)

[https://community.qualys.com/blogs/securitylabs/2010/10/06/d...](https://community.qualys.com/blogs/securitylabs/2010/10/06/disabling-
ssl-renegotiation-is-a-crutch-not-a-fix)

If you set security.ssl.require_safe_negotiation to false in about:config you
should be able to establish a connection.

[1] Edit: actually it's not; the parent poster had tweaked settings in
about:config ;-)

~~~
agl
Good to know. I knew that I needed to do it, but I'll be sure to add support
for this prior to Go 1.2.

(The TLS stack doesn't support renegotiation at all, so it's not vulnerable,
but a client can't know that unless it echos the extension in question.)

~~~
agwa
Ah, you're using the Go TLS package? That makes sense ;-).

As it turns out the latest version of Firefox still connects to servers which
don't indicate secure renegotiation; the parent poster caused the problem by
mucking around with the TLS settings in about:config.

~~~
nitrogen
Well, it looks like he _wrote_ the Go TLS package.

------
mike-cardwell
If anyone wants to test this with me, you'll find my contact details in my HN
profile and on [https://grepular.com/](https://grepular.com/)

Both of which contain my PGP details. So by sending my your handshake message
encrypted with my key, I'll reply with my handshake message encrypted with
your key, then we can test.

------
quantumpotato_
Why the "better relationship" quip? Get some e-mails from the CIA after
publishing this?

~~~
self
It's probably in reference to David Petraeus's resignation after his affair
came to light.

------
zhovner
I can not forgive Adam he removed the DANE support from Chrome in spite of
fact that he was the author of the draft standard
[http://datatracker.ietf.org/wg/dane/](http://datatracker.ietf.org/wg/dane/)

~~~
tptacek
Why does Langley need your forgiveness for not supporting DANE? DANE is
arguably worse than X.509 CAs.

~~~
9h1d9j809s
Why? Because DNSSEC can be attacked by the DNS root?

It seemed to be our best attempt to get SSL for every website. CA-based
certificates just won't cut it.

~~~
tptacek
Because replacing a PKI run by companies that the NSA can coerce with a PKI
run by the US Government doesn't seem like a good plan? That, along with the
litany of reasons why DNSSEC is a terrible design; that it doesn't secure
queries from stub resolvers where the need is greatest; that it publishes
internal zone names; that it breaks the resolver API and will inevitably
create outages; I can go on.

(I doubt this is what's held up DANE; rather, the unreliability of DNS
compared to hyper-optimized HTTPS/TLS connections is the issue there; browser
vendors care about milliseconds.)

------
zokier
I wonder how badly the security of Pond would break if one were to build a
pond-email gateway of some sort so that you could use regular imap/smtp
clients (and maybe tor).

------
ooorlllyyy
Woah, this is seriously cool stuff. I wonder how far off it is from general
readiness?

