5 ms·

Was just coming here to voice my concerns over this choice as well, wondering what their reasoning is for changing crypto systems.

by daguava 11y ago

scott_karana 11y ago
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.
thristian 11y ago
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.
- nailer 11y ago
  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.
  - drewbug 11y ago
    Agreed, this would be awesome.
  - dogma1138 11y ago
    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
- masklinn 11y ago
  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 http://article.gmane.org/gmane.os.openbsd.cvs/130612
Analemma_ 11y ago
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.
- lukeh 11y ago
  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.
DonnyV 11y ago
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.
- PlzSnow 11y ago
  No.
  - daveloyall 11y ago
    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."?
    - deleted 11y ago
      [deleted]
    - ionised 11y ago
      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.
      - PlzSnow 11y ago
        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.
- geofft 11y ago
  > 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?
xorcist 11y ago
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.

Was just coming here to voice my concerns over this choice as well, wondering what their reasoning is for changing crypto systems.

by daguava 11y ago

Was just coming here to voice my concerns over this choice as well, wondering what their reasoning is for changing crypto systems.

scott_karana 11y ago

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.

thristian 11y ago

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.

nailer 11y ago
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.
- drewbug 11y ago
  Agreed, this would be awesome.
- dogma1138 11y ago
  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
masklinn 11y ago
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 http://article.gmane.org/gmane.os.openbsd.cvs/130612

Analemma_ 11y ago

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.

lukeh 11y ago
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.

DonnyV 11y ago

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.

PlzSnow 11y ago
No.
- daveloyall 11y ago
  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."?
  - deleted 11y ago
    [deleted]
  - ionised 11y ago
    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.
    - PlzSnow 11y ago
      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.
geofft 11y ago
> 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?

xorcist 11y ago

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.