Hacker News new | ask | show | jobs
by daguava 3900 days ago
Was just coming here to voice my concerns over this choice as well, wondering what their reasoning is for changing crypto systems.
5 comments

I imagine it's nothing more complicated than "OpenSSL isn't the native crypto implementation on Windows, SChannel is". Microsoft's engineers are probably much more familiar with SChannel, and they don't want to have to test/validate two crypto systems in parallel. Besides, this should make OpenSSH better in the long run; it should be able to have any compatible crypto layer underneath.
SChannel implements SSL/TLS as a security support provider (SSP), native crypto interfaces are WinCNG (current) or CryptoAPI (legacy). A port of OpenSSH that used the native crypto library would likely use WinCNG.

An OpenSSL-like wrapper around WinCNG can be found in Heimdal's libhcrypto.

A crypto system is a big and complex thing, subtle and quick to anger, and I can't blame Microsoft for wanting to concentrate on the one they're already supporting, instead of having to support two.

On the other hand, for the exact same reason, I expect OpenSSH probably isn't interested in supporting anything besides LibreSSL and maybe OpenSSL, at least while they're so closely related.

So you think it'll remain a fork, rather than a platform for OpenSSH?

If they implemented a good openssl to cryptoAPI shim it could be usable by other projects linked against OpenSSL.

You can already configure OpenSSL to delegate the engine to CAPI which means that OpenSSL mostly works as a "shim".

[engine_section] capi = capi_config

[capi_config] engine_id = capi dynamic_path = c:\\openssl-win32\\bin\\capi.dll init=1

Agreed, this would be awesome.
You can already build OpenSSH without a libssl (make OPENSSL=no), it drops support for ssh1 and the only algos available are curve25519, aes-ctr, chacha, ed25519 (or were when it was first announced[0])

[0] http://article.gmane.org/gmane.os.openbsd.cvs/130612

Duplication of effort and attack surface. Now, instead of worrying about just keeping Windows' crypto api secure, Microsoft would have to worry about libressl as well?

Long term, if this is truly a first-party supported SSHd, it makes sense.

Also, keep in mind that modern OpenSSH does not need to link against OpenSSL anymore. You will have to make do with the bundled ciphers ed25519 and chacha, which is useless for talking to your legacy systems, but if you are making a new deployment it might suffice (or even be desirable).

The article is not clear if that's an option with this new Windows port, but it would decrease the attack surface a lot, which can only be good. SChannel has had its fair share of nasties over the years.

I really don't like that there replacing an open source crypto with a closed source one. Putting on my tin foil hat but didn't Microsoft hand over a back door to the NSA already.
> Putting on my tin foil hat but didn't Microsoft hand over a back door to the NSA already.

What incident are you referring to? I can think of a couple of possible ones:

1. PRISM, which is still a big question mark, and if it's in your threat model, then running Windows, let alone running Windows with an SSH server of any form, is not something you want to be doing, regardless of whether a particular library in it is open-source.

2. _NSAKEY, which MS had a decently convicing explanation of: it was a signing key used to indicate NSA-approved cryptographic providers (for FIPS-ish auditing), not anything that could be used to break into a user's account remotely.

3. The removal of the Elephant diffuser from BitLocker. My personal opinion is that all "diffusers", custom block cipher modes, etc. for full-disk encryption are pseudoscience; if you really want integrity protection, change your filesystem so it uses 4064-byte sectors, a 16-byte IV, and a 16-byte authentication tag. In any case, it still requires physical access to the disk to attack, so it's not particularly useful as an NSA back door (unless your threat model is one of the "then you have bigger problems" ones).

But maybe I'm forgetting something else?

The two cryptographers who originally publicly identified the backdoor (that Snowden eventually confirmed) work for Microsoft. So, the opposite of what you're insinuating.

http://rump2007.cr.yp.to/15-shumow.pdf

Always possible MS is not to be trusted, but there's nothing on the record to support that.

They collaborated with the NSA to develop an exploit in the SSL implementation used in Outlook.com.

From the Snowden documents;

July 31, 2012

Microsoft (MS) began encrypting web-based chat with the introduction of the new outlook.com service. This new Secure Socket Layer (SSL) encryption effectively cut off collection of the new service for FAA 702 and likely 12333 (to some degree) for the Intelligence Community (IC). MS, working with the FBI, developed a surveillance capability to deal with the new SSL. These solutions were successfully tested and went live 12 Dec 2012.

It's not clear this should be called an "exploit". It sounds like Microsoft in its capacity as a cryptographic endpoint turning over either plaintext or session keys (or in the severely worst case, long-term private keys). It doesn't make much sense to me to refer to that as an "exploit".
Actually, sorry that was the FBI they worked with.
No.
Sorry, I don't understand this response.

Are you saying that you are familiar with the events that DonnyV is referring to but you are confident that they are mere legend? That you disagree with the published accounts?

Or are you saying that you are not familiar with that particular scandal, you've never heard of it, and your response is simply "Not that I know of."?

If you check his post history he basically just blanket denies everything relating to the Snowden NSA leaks and accuses people of believing in 'magic' when they discuss the agency's capabilities.
That's not true at all. I question it when people post conspiracy theory stuff with no evidence whatsoever. HackerNews is not that type of website, and I hope it never degenerates into it.