Hacker News new | ask | show | jobs
by nailer 3900 days ago
> Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service

Was wondering about that. I'm surprised the OpenBSD team is accepting the commits - something so fundamental and Windows specific doesn't seem like their kind of thing - but great!

PS. If you're coming from a Unix background and interested in learning posh: https://certsimple.com/rosetta-stone

6 comments

Why would the OpenBSD team not accept the commits? It is just linking to a system library that will always be present on the platform. It's like saying Windows opensource should be forced to use some thrid party filesystem library.
My guess is they won't just write an openssl to schannel shim and instead sprinkle ifdefs throughout the code which would be a recipe for disaster.

Looking at the new code I feel like the chances this ever makes it upstream to pretty close to 0.

Schannel implements SSL; crypto is in WinCNG these days. SSPI support for Kerberos and EAP would be nice.
Raise an issue and ask?
I think that there is nothing to accept.

These patches are going to the portable version - which has always been a separately maintained branch of openssh. e.g. no PAM, no Kerberos ...

> PS. If you're coming from a Unix background and interested in learning posh: https://certsimple.com/rosetta-stone

I stopped reading this when I got to this part:

    whois 'domain [domain name]'
-->

    $web = New-WebServiceProxy 'http://www.webservicex.net/whois.asmx?WSDL'
    $web.GetWhoIs('[domain name]')
It's cute that there is some kind of VBScript for calling web services, but this line tells me that this document must have been authored by some kind of PowerShell apologist.

Just put none in the `whois` box and move on.

The main aim is to be useful. Someone who wants to lookup Whois is better served by giving them something that will achieve that task.

If you have other suggestions though, send a pull request. The project has already gotten a bunch from the SmartOS and FreeBSD communities.

If I could send a pull request to Microsoft for inclusion of a legit whois binary on their OS--nope, you're right, I'm just full of spite on this subject. :)
Actually, pretty sure most linux distributions don't ship with the whois binary.

(This is entirely based on the fact that I find myself installing it far too often)

That's a feature. My initial installations don't include much. Tools are installed the first time I need to use them.
Or hell, use something like https://github.com/bone187/PowerShell-Whois/blob/master/whoi.... I like PowerShell but sometimes the community makes me wonder.
That's certainly a lot cleaner than using the WSDL implementation. I've bumped the release on npm and used this instead - thank you.

If anyone else on HN wants to add anything, the source is just markdown, so you can hack away (gulp does the HTML building and JS does the interactivity): https://github.com/certsimple/rosetta-stone/blob/master/rose...

Was just coming here to voice my concerns over this choice as well, wondering what their reasoning is for changing crypto systems.
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.
I'm surprised the OpenBSD team is accepting the commits

Theo has come a long way since he lost beaucoup bucks by spitting in DARPA's face after taking their money.[1] Now Microsoft and OpenBSD are besties.[2]

There are a few companies that give money to OpenBSD. Far too few, but there are some: http://www.openbsdfoundation.org/contributors.html

The saddest thing to me is that Yandex is on there. Not because they shouldn't be, but because so many American and Western companies are willing to take, take, take, but are unwilling to give back even a little bit.

[1] http://www.computerworld.com/article/2580728/security0/darpa... [2] http://www.theregister.co.uk/2015/07/08/microsoft_donates_to...

>I'm surprised the OpenBSD team is accepting the commits

What commits? From the comments you will learn there were no commits and this is a classic embrace and extend. They are hijacking OpenSSL name, and rewriting it to use Microsoft crypto and APIs.

...what? It's there on the repo. It's not upstreamed yet, no.

I think this is a fantastic step forward. If you've never been subjected to WinRM you may not understand why this is such a big deal.

OpenSSH is not OpenSSL!