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

SslStream AuthenticateAsClient method is not sending SNI information to the server on OS X #20741

Closed
rstam opened this issue Mar 23, 2017 · 12 comments
Assignees
Milestone

Comments

@rstam
Copy link

@rstam rstam commented Mar 23, 2017

When using AuthenticateAsClient to connect to a server, SslStream does not appear to be sending the SNI information to the server.

We have observed this issue on OS X. When running on Windows the SNI information does appear to be sent. It is unknown to us whether the SNI information is sent when running on Linux.

@davidsh
Copy link
Contributor

@davidsh davidsh commented Mar 23, 2017

Not sure if this is related to #17677. SslStream has limited supported for SNI in general and does not support SNI on the server-side (AuthenticateAsServer).

@mongostephen
Copy link

@mongostephen mongostephen commented Mar 23, 2017

Just a note, on Windows, SslStream appears to pass on SNI.

@Priya91
Copy link
Contributor

@Priya91 Priya91 commented Nov 21, 2017

The client Sslstream on Linux also sends sni headers.

@karelz
Copy link
Member

@karelz karelz commented Dec 4, 2017

Seems to have impact on MongoDB client driver, moving to 2.1

@Priya91
Copy link
Contributor

@Priya91 Priya91 commented Dec 7, 2017

I wrote a small app on MacOS and hit a websocket server using ManagedClientWebSocket and an https server using ManagedHttpClientHandler, both of these types uses SslStream in their implementation. I verified the ssl handshake data sent over the wire using wireshark, and verified that it in fact sends the server_name TLS extension in the ClientHello. Can you provide a small repro app for this bug, along with the ssl handshake header information?

@karelz
Copy link
Member

@karelz karelz commented Dec 13, 2017

Closing, feel free to reopen when there is a repro we can look at.

@karelz karelz closed this Dec 13, 2017
@ar7z1
Copy link

@ar7z1 ar7z1 commented Feb 8, 2018

@karelz @Priya91 I've faced the same problem on my linux box. I use dotnet-runtime-2.0.5.

A small program to reproduce the issue:

using System;
using System.Net.Security;
using System.Net.Sockets;
using System.Security.Authentication;

namespace TestSNI
{
    class Program
    {
        static void Main(string[] args)
        {
            var host = "cluster0-shard-00-00-fvaks.mongodb.net";
            using (var client = new TcpClient(host, 27017))
            {
                using (var sslStream = new SslStream(client.GetStream(), false))
                {
                    sslStream.AuthenticateAsClient(host);
                }
            }
        }
    }
}

On Windows this code sends SNI extension:
image

But on Linux (I've tested on Ubuntu 14.04 and Ubuntu 16.04) it doesn't:
image

Pcaps for Windows, Ubuntu 14.04 and Ubuntu 16.04: SNI.zip.

I think that the problem is because awesome fix from @Priya91 (#25118) doesn't exist in v2.0.5: https://github.com/dotnet/corefx/blob/v2.0.5/src/Common/src/Interop/Unix/System.Security.Cryptography.Native/Interop.OpenSsl.cs#L108

@karelz
Copy link
Member

@karelz karelz commented Feb 8, 2018

Yes, client-side SNI was added into 2.1. Did you try to run it on 2.1? (see dogfooding)

@ar7z1
Copy link

@ar7z1 ar7z1 commented Feb 9, 2018

@karelz I've checked the master nightly build, everything is perfectly working!
Is there any chance to release this feature before 2.1? Then many people will be able to use MongoDB with ssl on Linux. :-)

@karelz
Copy link
Member

@karelz karelz commented Feb 9, 2018

If there is strong demand to have it in 2.0.x (i.e. it is adoption blocker for a few customers), we could consider it. So far I have seen moderate demand (5-ish people asking about it / reporting it - and only this one asking for servicing fix).
Also, the 2.0 servicing fix might be available quite close to 2.1 availability, so the value of porting goes down. If it is blocking you badly, did you consider porting the fix into 2.0.x branch and creating custom build with local fix?

@ar7z1
Copy link

@ar7z1 ar7z1 commented Feb 9, 2018

the 2.0 servicing fix might be available quite close to 2.1 availability

@karelz Then I'll wait till 2.1. :-)

Thank you again for awesome work!

@paulcsiki
Copy link

@paulcsiki paulcsiki commented May 29, 2018

I'd also like a port to 2.0 as our company's policy is to wait a couple of months before adopting a new framework version into a production service. This is a showstopper for us too.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.1.0 milestone Jan 31, 2020
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Dec 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants