Skip to content

Conversation

@dantraMSFT
Copy link
Contributor

PR Summary

This changes ensure WSMAN_OPTION_UNENCRYPTED_MESSAGES is set when using Basic auth over HTTP. On Linux and macOS, not setting this option explicitly fails the connection request.

PR Checklist

SetWSManSessionOption(WSManNativeApi.WSManSessionOption.WSMAN_OPTION_USE_SSL, 1);
}
if (connectionInfo.NoEncryption)
if (connectionInfo.NoEncryption ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After thinking about this I am uncomfortable making PSRP messages non-encrypted by default for Basic auth. Basic auth is not recommended but I am sure many customers use it, and may rely on PSRP messages being encrypted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PaulHigin: I limited the change to UNIX. PSRP/MI don't support encryption over HTTP like PSRP/WIndows/WSMan does.

@dantraMSFT
Copy link
Contributor Author

FYI: The -workingdirectory test failure is being addressed with PR #6723

@SteveL-MSFT
Copy link
Member

I'm concerned about this being enabled by default on Unix. On Windows, the user needs to enable AllowUnencrypted for both the client and server to work and is only intended for developer use. Basic auth over unencrypted HTTP means the creds are in plain text over the wire. Seems like we should make the user specify explicitly they are ok with this somehow.

Copy link
Member

@SteveL-MSFT SteveL-MSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be explicitly opt-in

@dantraMSFT
Copy link
Contributor Author

@SteveL-MSFT : What do you mean by explicitly opt-in? Right now, it's not possible at all from Linux because flags are not set appropriately. of course, it's till not possible from Linux to Windows without configuring the WSMan settings appropriately.

Are you suggesting that we replace the -UseSLL and have -AllowUnencrypted?

@SteveL-MSFT
Copy link
Member

@dantraMSFT not replace, but perhaps add that switch

@dantraMSFT
Copy link
Contributor Author

On Linux, encryption over HTTP is simply not supported and we would need to introduce a breaking change to require an explicit opt-in. I think there's one of three approaches

1: The user would have to explicitly select -UseSSL or -AllowUnencrypted since selecting need is an unsupported state.

2: -UseSSL would need to be the default behavior.

3: Change OMI to have a policy that needs to be explicitly enabled, such as we have with WSMan::localhost\Service\AllowUnencrypted.

@paulcallen
Copy link
Contributor

encryption over HTTP is only supported with Kerberos, NTML and CredSSP (the last one not supported on Linux)

@dantraMSFT
Copy link
Contributor Author

Closing due to #6787 (Disallow Basic Auth over HTTP on Unix)

@dantraMSFT dantraMSFT closed this May 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants