3 ms·

> Not to mention the random SSL downgrades that happen when you're going via UK transit links. (Which I have experienced myself!) I live in the UK and have nev

> Not to mention the random SSL downgrades that happen when you're going via UK transit links. (Which I have experienced myself!) I live in the UK and have never experienced this. Could you provide a source? I don't think that is something that's happening.

dijit 9y ago
It happens, but usually on traffic passing through the UK from europe on it's way to USA, and I don't know the intricacies of how it works but it doesn't downgrade high profile ports/IPs (like google, facebook). in my case it was a IRC server which was built identically to another 2 nodes in other parts of the world- When I looked into why I found no good reason so I dug in to it and was presented with a GCHQ/NSA project called "Tempora". I ran a bunch of tests using the popular `openvpn` software suite and a bunch of VPS providers who were cheap enough (tilaa, vultr, linode and AWS) and the common trend was exactly what I described. If I pinned the ciphers then the data would not be tampered, if I allowed a weaker cipher then my "response" would say the server was only capable of TLS1.0 despite me connecting to the same server minutes earlier on a different port with TLS1.2. I will do a write-up on this and submit to HN as I assume this is still in place and all references to what I describe seem to have been removed from google. I'm beginning to feel like one of those tin-foil hat people since I spent considerable time looking at documents surrounding this before and it's just vanished. :(
- paralelogram 9y ago
  In 2003-2004 I had a non-SSL IRC server in a German datacenter and found that something between my server and large British ISPs was rewriting all "ISON <nickname>" strings in TCP streams to "PRIVMSG <nickname> :!kapa". I moved the IRC server to another IP address and never had this problem again. I think that GCHQ was monitoring the network traffic and had a bug in their IRC protocol implementation.
- libeclipse 9y ago
  I'm skeptical, but unsurprised. Did you eliminate all other factors? Bugs on the client/server side? When you do this write-up, or if you need any help with it, pop me an email (awn#cryptolosophy.io).
- 45h34jh53k4j 9y ago
  I am also very interested in proof of this. So far we have no evidence of mass downgrades on TLS, its not in any of the leaked docs. Tempora is a GCHQ/NSA passive capture technology. Edit: Are you sure it isn't an old version of OpenSSL on your host? Last time i checked most IRCd's did SSLv3 (IRC crypto is awful btw.. stop using it)
  - dijit 9y ago
    This is something I am certain of. They were running exactly the same software, I was running FreeBSD 10.0 at the time with libressl 2.1.1 and irc was using gnutls 2.8.1 I'm going through my IRC logs now and this was my response to the same question. Regardless I was using the same server with the same versions and different cipher sets and a different port with the same software and getting inconsistent results _only_ when the path went via the UK. The same connection from Haarlem, NL to Sydney, AU was not affected by this inconsistency.

dijit 9y ago

It happens, but usually on traffic passing through the UK from europe on it's way to USA, and I don't know the intricacies of how it works but it doesn't downgrade high profile ports/IPs (like google, facebook). in my case it was a IRC server which was built identically to another 2 nodes in other parts of the world- When I looked into why I found no good reason so I dug in to it and was presented with a GCHQ/NSA project called "Tempora". I ran a bunch of tests using the popular `openvpn` software suite and a bunch of VPS providers who were cheap enough (tilaa, vultr, linode and AWS) and the common trend was exactly what I described. If I pinned the ciphers then the data would not be tampered, if I allowed a weaker cipher then my "response" would say the server was only capable of TLS1.0 despite me connecting to the same server minutes earlier on a different port with TLS1.2. I will do a write-up on this and submit to HN as I assume this is still in place and all references to what I describe seem to have been removed from google. I'm beginning to feel like one of those tin-foil hat people since I spent considerable time looking at documents surrounding this before and it's just vanished. :(

paralelogram 9y ago
In 2003-2004 I had a non-SSL IRC server in a German datacenter and found that something between my server and large British ISPs was rewriting all "ISON <nickname>" strings in TCP streams to "PRIVMSG <nickname> :!kapa". I moved the IRC server to another IP address and never had this problem again. I think that GCHQ was monitoring the network traffic and had a bug in their IRC protocol implementation.
libeclipse 9y ago
I'm skeptical, but unsurprised. Did you eliminate all other factors? Bugs on the client/server side? When you do this write-up, or if you need any help with it, pop me an email (awn#cryptolosophy.io).
45h34jh53k4j 9y ago
I am also very interested in proof of this. So far we have no evidence of mass downgrades on TLS, its not in any of the leaked docs. Tempora is a GCHQ/NSA passive capture technology. Edit: Are you sure it isn't an old version of OpenSSL on your host? Last time i checked most IRCd's did SSLv3 (IRC crypto is awful btw.. stop using it)
- dijit 9y ago
  This is something I am certain of. They were running exactly the same software, I was running FreeBSD 10.0 at the time with libressl 2.1.1 and irc was using gnutls 2.8.1 I'm going through my IRC logs now and this was my response to the same question. Regardless I was using the same server with the same versions and different cipher sets and a different port with the same software and getting inconsistent results _only_ when the path went via the UK. The same connection from Haarlem, NL to Sydney, AU was not affected by this inconsistency.