Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow a custom HttpMessageHandler to support overriding the verification of Self-Signed SSL certificates. #42

Closed
ElasticCoder opened this issue Feb 15, 2019 · 16 comments
Assignees
Labels
discussion-wanted Need a discussion on an area feature-request New feature or request

Comments

@ElasticCoder
Copy link

ElasticCoder commented Feb 15, 2019

With the V2 client now using the latest framework it is possible to override the HttpMessageHandler and override self-signed certificate checking.

	var handler = new HttpClientHandler();
	handler.ClientCertificateOptions = ClientCertificateOption.Manual;
	handler.ServerCertificateCustomValidationCallback += DangerousAcceptAnyServerCertificateValidator;

	_client = new DocumentClient(new Uri(_documentDbOptions.Endpoint), _documentDbOptions.Key, handler);

However with the V3 client, there is no ability to do this.
Can we look for a suitable way to do this?

Self-Signed certification verification overrides are required when running on Linux clients that wish to connect to the emulator. Despite all of the good work that has been done with the emulator such as allowing you to specify the alternative subject names for the self-signed certificate and export it, there are still limitations. I've found that the Linux implementation of .NET core that uses cURL/OpenSSL will still error with a self-signed certificate, even if you install it into the ca-certificates store. (Windows will honor the certificate if you put it into the Trusted Certificate Authorities store).

It would be preferable to use the V3 SDK rather than the V2.

@ElasticCoder
Copy link
Author

I'm having a look through the source code to see how this might be done.

Initially, it looks difficult. The example above uses the HttpClientHandler which derives from the abstract HttpMessageHandler. The Cosmos DB client framework uses a different derivative, HttpRequestMessageHandler which derives from a DelegatingHandler and the abstract HttpMessageHandler.

Unfortunately this chain does not have access to the same ClientCertificateOptions and ServerCertificateCustomValidationCallback properties.

@ElasticCoder
Copy link
Author

ElasticCoder commented Feb 17, 2019

I've got a working solution. I'll start to prepare for a pull request.

I've chosen to add a DisableSslVerification property to CosmosConfiguration, using the same property name that was used in the previous Java/Python SDKs.

var cosmosConfiguration = new CosmosConfiguration(accountEndpoint, accountKey)
{
    DisableSslVerification = true,
    ConnectionMode = ConnectionMode.Gateway
};

@j82w j82w added feature-request New feature or request discussion-wanted Need a discussion on an area labels Feb 19, 2019
@ElasticCoder
Copy link
Author

@j82w would you like to discuss this?

@j82w
Copy link
Contributor

j82w commented Mar 1, 2019

I'm worried that there are other scenarios that will be blocked by not having the same access in v2. This approach will not scale nicely if multiple other options need to be exposed.

@kirankumarkolli do you know if this is the only option that will be needed or do we need to find a better way to expose the different options?

@ElasticCoder
Copy link
Author

ElasticCoder commented Mar 1, 2019

@j82w Thanks for replying. Can you clarify what do you mean by "options"?

Are you concerned that the DisableSslVerification property is too specific to HTTP Gateway connections and will cause property bloat? Should it be encapsulated within a connection abstraction?

I took some comfort that the DisableSslVerification property was present on the Java and Python SDKs, but if you think we should do something different I'm happy to have another look at it so we can get the best solution.

@j82w
Copy link
Contributor

j82w commented Mar 1, 2019

I am not to worried about the property bloat since Java and Python SDK have it.

I'm more interested in is if there are other scenarios that are being blocked by not having the ability to override the HttpClientHandler. It exposes a lot of properties which the HttpMessageHandler does not have. If users need access to all of those properties that are no longer available then we should find a better way to expose it.

@manuelsidler
Copy link

@ElasticCoder Our local development environment is behind a proxy. That's one scenario where we need to override the HttpClientHandler to set a proxy. We already do that for Azure Storage and Search client SDKs. But I couldn't find a way in the new Azure Cosmos SDK.

@ElasticCoder
Copy link
Author

@ElasticCoder Our local development environment is behind a proxy. That's one scenario where we need to override the HttpClientHandler to set a proxy. We already do that for Azure Storage and Search client SDKs. But I couldn't find a way in the new Azure Cosmos SDK.

Thank you, that is a good concrete example. I'll have a look at the code impact.

@ElasticCoder
Copy link
Author

I may have found a way to inject an HttpClientHandler into the DocumentClient which should satisfy the requirements that @schueh and @j82w have raised. I will have a look at this next week.

@ElasticCoder
Copy link
Author

I have addressed this requirement now with #74 which allows the consumer to specify a custom HttpMessageHandler.

@zhengwia
Copy link

Hi any plan on this pr going to release? Same situation working behind a corporate firewall. Thanks.

@ausfeldt ausfeldt self-assigned this Aug 27, 2019
@kirankumarkolli
Copy link
Member

.net standard 2.0 now seems has supports for custom SSL handling.

@ausfeldt started investigating and will update with details.

@ausfeldt ausfeldt mentioned this issue Aug 28, 2019
2 tasks
@kirankumarkolli
Copy link
Member

kirankumarkolli commented Aug 28, 2019

@ElasticCoder we have a PR (#743 ) with the required changes.
If possible can you please validate it?

@zhengwia
Copy link

zhengwia commented Sep 5, 2019

Saw the pr merged to master! thanks guys looking forward to the next build!

@ealsur ealsur closed this as completed Oct 11, 2019
@galvesribeiro
Copy link

Folks, how is that PR fixing the SSL bypass issue? I don't see how to set the HttpClientHandler or other way to ignore the SSL cert. I'm on OSX with the same issue on the emulator...

Can someone shed a light on this? Thanks!

@j82w
Copy link
Contributor

j82w commented Jan 27, 2021

Just in case anyone finds this issue it was fixed in 3.12.0.

Here are examples on how to configure it:

CosmosClientOptions cosmosClientOptions = new CosmosClientOptions()
{
    HttpClientFactory = () =>
    {
        HttpMessageHandler httpMessageHandler = new HttpClientHandler()
        {
            ServerCertificateCustomValidationCallback = (req, cert, chain, errors) => true
        };
        return new HttpClient(httpMessageHandler);
    },
    ConnectionMode = ConnectionMode.Gateway
};


CosmosClient client = new CosmosClient("https://localhost:8081", 
    "C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==", 
    cosmosClientOptions);

Or if you are using a NET Standard 2.1 project:

CosmosClientOptions cosmosClientOptions = new CosmosClientOptions()
{
    HttpClientFactory = () =>
    {
        HttpMessageHandler httpMessageHandler = new HttpClientHandler()
        {
            ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator 
        };
        return new HttpClient(httpMessageHandler);
    },
    ConnectionMode = ConnectionMode.Gateway
};


CosmosClient client = new CosmosClient("https://localhost:8081", 
    "C2y6yDj", 
    cosmosClientOptions);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion-wanted Need a discussion on an area feature-request New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants