Hello…
QUESTION 1
Are any of the main authors aware of a way to disable HTTPS in the Golang code for development?
I want to use wireshark to sniff the local packets so I can look more closely at the BEP and uPnP packets and protocol. I turned on the various debugging features, but they don’t offer the ability to save packets in libpcap format – they just print out to stdout or stderr or whatever.
I’m fine modifying the code, but it’s a bit of a slog since this is my first delve into a Go project.
Ideally, I’d want to be able to just disable HTTPs so I can load up a couple of instances of the Go code in VMware w/ internal networks, so I can look more closely at the packets.
Unfortunately since everything is HTTPS with DH key exchange, even if I use the X509 certs, I can’t easily decrypt the packets . . . Even with a custom mitm proxy, it’s a pain in the neck. I could spit out the session key but this would take forever to get working properly.
The point is to look more closely at both the UDP and TCP packets, data structures, and so forth without any TLS encapsulation. I’d love to just have a ‘plaintext’ pcap dump of all the network traffic to examine more closely.
Any ideas on an easy way to accomplish this?
QUESTION 2
Is there any formal documentation and /or definitions on how to ‘talk’ to a local Syncthing instance, like for purposes of writing a new client GUI? I notice there is a pretty impressive GTK client, but I’d like to know if there was some documentation (besides the BEPv1 document) that the GTK client author referred to in order to execute commands on the server.
Similar issue here in terms of ‘reverse engineering’ the correct protocol for ‘talking’ with the server. Much easier to do if you can see what’s going out and coming back over the wire. I suppose the debug mode is okay, but I’d like something a bit more powerful… Or even better, documentation and/or examples on which commands and packet structures do what, the order of operations, and so forth.
QUESTION 3
Did my post on $10 million NSA and RSA collaboration to put backdoors into crypto go to the great hard drive in the sky-- or does my internet just suck? I think it’s pretty relevant.
I can understand the implications may be controversial. But it was a mainline / vanilla Reuters story, and (regrettably) it’s not like the facts themselves are in dispute.
Given that the transport security of this software (Syncthing) is based upon the assumption that TLS is secure, and the fact that TLS is based upon (in large part) ‘de facto’ NIST standards – in particular, the RSA-based primitives, AES and it’s modes, and certain ECs over finite fields etc…
My question is why would a post (from Reuters nonetheless) about collaboration between the NSA and RSA to insert backdoors into crypto not be important , at least as something to consider in terms of design and architecture ?
I’d think this would be especially pertinent to which TLS modes and ciphers Syncthing should support – and which TLS modes could be considered ‘deprecated’ by Syncthing – and perhaps either rejected or a warning issued to the user?
Another key point here in the same line of thinking is whether TLS modes w/ PFS utilizing RSA should be preferred over ECs w/ PFS , or vice versa , especially in light of the original revelations of hidden connections between RSA and NSA.
The former algorithm – RSA – is only as secure as the premise that the factoring of large composite integers is a suitably difficult / intractable problem. However, there exists no mathematical proof that there is no ‘shortcut’.
In other words, there is no way to prove that to break RSA you must brute-force with Number Field Sieve.
No polynomial-time method for factoring large integers on a classical computer has yet been found, but it has not been proven that none exists.
Meaning that there is no proof that RSA is ‘as hard’ as factoring the modulus. This is even if we disregard quantum attacks as improbable / impossible.
Granted: there are mathematical relationships between breaking RSA and breaking ECs. Recent papers suggest that if you can ‘break’ one you can ‘break’ the other. So that much I can understand.
But what we DO know about EC is that their security is based on the premise of solving a discrete logarithm over a finite field (arguably preferable to factorization), ECs are utilized in the NSA Suite B standards (used for protecting Secret / Top Secret data), and ECs are more efficient to calculate.
Additionally, if we are to consider utilization of independent (non-NIST) ECs like curve25519 with TLS, we begin to have some degree of confidence that the we are not working with a deliberately or inadvertently weakened system.
There are still issues – both schemes (RSA and ECs) are vulnerable to quantum attacks with Shor’s algorithm, although ECs can be made resistant to such attacks with Supersingular Isogeny DHE… Such technology does not (to my knowledge) exist for RSA.
To avoid quantum computing concerns, an elliptic curve based alternative to Elliptic Curve Diffie Hellman which is not susceptible to Shor’s attack is the Supersingular Isogeny Diffie–Hellman Key Exchange of De Feo, Jao and Plut. They use elliptic curve isogenies to create a drop in replacement for the quantum attackable Diffie–Hellman and Elliptic curve Diffie–Hellman key exchanges. This key exchange utilizes the same elliptic curve computational primitives of existing elliptic curve cryptography and requires computational and transmission overhead similar to many currently used public key systems.[36]
In any case, I think it’s probably a wise idea for any security software using TLS to have a debate on crypto design decisions in light of the RSA revelations. Every year seems to bring another serious SSL/TLS attack, whether heartbleed, lucky13, various padding oracles, BEAST, MitM attacks, MAC authentication/encryption misordering, and other incredibly massive ‘fails’ … Certainly we should discuss such issues, or at least be aware of the pitfalls …
Particularly important I think is the question of whether to enforce particular modes in TLS (modes which ensure perfect forward secrecy), and whether to prefer RSA over EC (or vice versa)…
This is especially important since a healthy plurality of all browsers do not support TLS modes with PFS… Most browsers do not support TLS 1.1 / TLS 1.2 , and are (somewhat astonishingly) using vulnerable RC4 implementations for which attacks are not merely academic – they are are a reality and routinely occur in the wild.
Heck , 80% of the top 150,000 web sites using SSL/TLS are still vulnerable to BEAST!
Survey of the SSL Implementation of the Most Popular Web Sites https://www.trustworthyinternet.org/ssl-pulse/
A significant number of internet browsers / server sites are essentially about as secure as a WEP-based access point, and can be broken within a few hours, due to statistical biases in the first 8k of the RC4 keystream.
Not to mention the fact that we can always attack the CA system – if a single root CA is malicious or compromised, it’s trivial to decrypt pretty much all RSA-based internet traffic, no matter what symmetric algo it’s using for transport secuirty.
Fortunately, the CA attack does not apply to Syncthing due to the wise design decision to ‘opt-out’ of the CA system altogether – in favor of a web-of-trust / shared-secret security model. But some of these other problems may apply, particularly with older OSs and browsers.
Avoiding RSA may be far preferable in light of the media revelations that RSA and the NSA deliberately weakened NIST standards with regards to CSPRNGs – whether this occurred with the knowledge and consent or RSA is a bit of a moot point.
Another angle to consider (which favors enforcement of RSA-based modes) is that ECs are more vulnerable to bad CSPRNGs since ECs are more ‘entropy hungry’ – in the case of poor entropy sources (ie. older versions of Windows), then RSA is perhaps the stronger candidate.
My hope was to encourage some thinking about (A) avoiding side channel attacks in general, and (B) whether it makes sense to force certain SSL/TLS modes as ‘obsolete’ and/or others are ‘preferred’.
QUESTION 4
During development of the original reference client, how did you guys handle debugging across the wire? Do you first get it working with HTTP, then enable TLS? Or was there another tactic that was used to ensure that a client and server were having an appropriate exchange of messages, populating local vars with the correct data, ensuring there were no mix-ups between big-endian / little-endian (host vs network byte order) and so on?
The best way I can think of is to have two virtual machines on the same subnet, with HTTPs disabled, and sniff the traffic while setting breakpoints in the respective IDEs on both sides of the session.
Is there a better way, or is this how you guys developed this originally?
QUESTION 5
What IDE are you guys using for Go? And on what OS? Is LiteIDE on Debian a suitable environment?
We have the luxury/limitation of depending on the Go TLS implementation. This has advantages and disadvantages. A disadvantage is that some cool stuff like the latest curves and ciphers are not implemented yet. An advantage is that we carry all the code with us in the binary. It doesn’t matter the least what version of OpenSSL you have or what browser you run. (At least for the sync connection. For the GUI, your browser is of course involved.)
That code is autogenerated by the 
