xnull

The overall question is whether bindings or language features that expose direct control of the underlying architecture (such as D) can still be used to implement crypto. The answer is likely yes, though it is uncharted territory that only someone who knows what they are doing should attempt.

STARTTLS was never intended to thwart MITM however. We need to keep that in mind. It allows a way to start a secure channel that is backwards compatible under the assumption that an attacker can eavesdrop but not manipulate the contents of the channel. In this regard it is some measure of an improvement.

For the record I do not think it is a final solution (what is). I do often have mixed feelings about 'the perfect being the enemy of the good'. With STARTTLS my feelings aren't as mixed. A measurable improvement to passive surveillance for minimal changes and no new infrastructure. Swell.

Again, not going to condone it as a panacea - but it's never advertised itself as one.

Let's keep using it until there's something better. And let's get furious at ISPs that strip it (or modify our traffic in any significant way).

It has its own ("Network Security Services" or NSS).

But that's not a reason to use Firefox on XP. ;)

The window from disclosure of patches to duplication is narrowing and it appears from the bulletin that client connections are affected as well. Furthermore any computer you take anywhere outside your home router (and can you really trust your home router as security boundary nowdays?!) will be easy to manipulate into an SChannel connection. Inside your home network, clients are still vulnerable to attack - any javascript/flash ad/referer can point a computer behind a router at an attacker server and serve up malicious SChannel packets. That is to say your home computer can be attacked on outgoing connections which your router will be happy to allow.

It's very serious. Patch immediately.

> Net neutrality isn't a blanket term for "anything the government does relating to the Internet", it's focused on a specific issue.

Of course.

> I guess you could argue that net neutrality would make it easier to pass pro-surveillance laws, but I'm having a difficult time connecting the two.

The argument wouldn't be that net neutrality itself would make it easier. The argument would be that the regulation - especially if the folds ISPs under telecommunication laws or equivalents - could result in the import of large portions of legislation pertaining to communications access programs.

Much of this has actually already been done at the ISP level and the (surveillance) struggle seems mostly focused on the application layer.

So I guess I might agree that it may not bolster surveillance capabilities - if only for the fact that ISPs have already been mostly captured.

Some here may know me as a critic of overreaching and aggressive cyber enforcement (and related surveillance).

First, I'm quite happy that this activity does not appear to be the result of wide scale infrastructure sabotage.

And I am quite happy that the FBI is doing its job to combat crime that is facilitated using (abusing) the technologies that are bastions for free speech, privacy and whistleblowing.

Of course the flipside is that this means that there are capabilities in place to disrupt anonymizing technologies - the technologies make investigation more expensive but ultimately are merely an inconvenience to the powers that be. So when it comes down to it, anonymizing services and Tor can't be trusted to secure you if you have something to say where your life is in danger.

The FBI (/others) wants the court system to replace technology as the gatekeeper to investigation. The court system, however, is brittle. It takes time, it fails, and it responds to external pressure - there are repeated studies that show that the length of time persons in US court systems are convicted to serve is highly correlated with how long it has been since the precising judge has eaten his last meal. There are also extralegal rights that law enforcement are given by legislature and evolving interpretations of what both these legal and extralegal rights entail.

But law enforcement also is justified from their perspective. They don't want there to be criminals that get away with crimes simply because criminals load up some software that obfuscate their identities, locations and accounts. If you look at this published list there are criminal organizations that you and I as taxpayers do want taken down. (I recognize that the sale and consumption of drugs is a greyer area of morality as drug use is sometimes victimless).

I think that for the most part law enforcement is capable of taking down these services and organizations other ways - ordering assault rifles and monitoring the drops - and that this provides opportunities for the government to enforce the law without sabotaging communications infrastructure. Taking down some .onion addresses doesn't do too much besides annoy the services for a time anyway unless the services operationally are not capable of standing up a new address and communicating with customers anonymously.

All in all it's a blurry line but I feel safer with places that are anonymous and secure than I do by trusting a court system and legal process that can only see, process, and be accountable for so much.

I think implementation bugs are within the spirit of OP, especially provided the NSA claims to have provided an implementation fix for Heartbleed.

The sorts of bugs I'm talking about exist in client and popular software. As far as tempo is concerned this year alone has given us BERserk, gotofail, Android Master Key, OpenSSL fork(), Bitcoin's use of P256, GNUTLS X.509 parsing bug, the OpenSSL compiler optimization+processor family randomness bug, and others.

If we were to entertain OP's point maybe there would be a faster tempo if the NSA were helping out. :)

Bug volume in crypto is extremely high. How many developers reuse IVs in stream ciphers? How many blindly use AES or somesuch other symmetric library and then build in no authentication whatsoever? How many antequated implementations of RSA are used in practice today (see recent Bleichenbacher flaw in NSS)? How many times are poor chaining modes for block ciphers chosen? How many implementations of [anything] fail on side cases (elliptic curves) or massively leak through side channels? How many DH-family protocols miss checks for identity inputs?

The answer is a lot.

Right, NEC3's 'solution' to obscure zones by signing hashes effectively just renames zones that probably come from some small collection ('www', 'ftp', 'ns', 'smtp', 'ilo') and not secure for the same reason hashing phone numbers is ineffective.

Arguments that administrators can choose names with large entropy would miss the point as it puts an undue burden on administrators and users to use 'bizarre' names.

Further arguments that you can brute force names using normal ol' A records also miss the point. The difference is online versus offline enumeration.

> it's based on RSA PKCS1v15

Eww. I had no idea. Next you'll tell me the root key's public exponent is 3. Gross.

> If your most important adversary is GCHQ and NSA, then the Internet is far more threatened by the deployment of DNSSEC than it is by DNSSEC's absence.

Not sure it makes too much of a difference in this case... you can't trust non-signed DNS records if your adversary is NSA/GCHQ, and you can't trust typical PKI to bail you out either.

Six digits sounds about right for a Tor bug for one target depending on the specifics. The RCE bug used by the FBI recently against the Tor Firefox Bundle would have cost something similar, though the payload suspended the process where it could have resumed silently. It's not clear where that exploit was developed (my gut says in house but who knows?)