Adam Langley's Pond: Secure Async Messaging
pond.imperialviolet.org
pond.imperialviolet.org
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.
|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.
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
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.
also, is code like this https://github.com/agl/pond/blob/master/server/server.go#L15... 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!
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 ;-)
"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)
}
Looking at the spec, I see that signed integers are elsewhere defined to be represented using 2's complement, so this is completely kosher.
Also, btw, I still have your AMOP,a nd it would be awesome to see you again.
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?
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.https://www.ssllabs.com/ssltest/analyze.html?d=pond.imperial...
https://wiki.mozilla.org/Security:Renegotiation
https://community.qualys.com/blogs/securitylabs/2010/10/06/d...
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 ;-)
All this week this was the first website to fail because of that.
It works with it set to false.
(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.)
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.
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.
It seemed to be our best attempt to get SSL for every website. CA-based certificates just won't cut it.
(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.)