-
Notifications
You must be signed in to change notification settings - Fork 141
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
Don't call validateSNIServerName when TLS hostname verification is disabled #380
Conversation
Enable connections to IP addresses without hostname verification Modifications: Don't call validateSNIServerName when TLS hostname verification is disabled Result: Connections to IP addresses with certificateVerification = .noHostnameVerification are possible
Can one of the admins verify this patch? |
10 similar comments
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for filing this!
This behaviour is not a bug: validateSNIServerName
is validating that the name provided as the serverHostname
argument is a valid SNI string. This is not validating that it matches the name provided in the server certificate, but instead confirming it's acceptable for us to send it in the handshake extension.
The extension is defined in RFC 6066 § 3, which contains the following constraints:
Literal IPv4 and IPv6 addresses are not permitted in "HostName".
"HostName" contains the fully qualified DNS hostname of the server, as understood by the client.
A DNS hostname forbids embedded NULs and can be no more than 255 bytes long.
Thanks for the explanation! That makes total sense. It seems that the bug is in the higher level library that I'm using: https://github.com/vapor/websocket-kit/blob/main/Sources/WebSocketKit/WebSocketClient.swift#L100 I suppose the proper fix would be to check there if the host is an IP address and if so, pass |
Yup, that would work. Alternatively, the wrapper library could catch those specific errors and re-create the handler without the SNI, as the errors are localised and only thrown from there. |
Ah good idea, catching the error would definitely be cleaner. Unfortunately the compiler is complaining:
let tlsHandler: NIOSSLClientHandler
do {
tlsHandler = try NIOSSLClientHandler(context: context, serverHostname: host)
} catch NIOSSLExtraError.cannotUseIPAddressInSNI {
tlsHandler = try NIOSSLClientHandler(context: context, serverHostname: nil)
} Am I catching the error incorrectly or does |
I think you need a longer catch let error as NIOSSLExtraError, error == .cannotUseIPAddressInSNI |
Got it working with catch let error as NIOSSLExtraError where error == .cannotUseIPAddressInSNI Thanks so much for all the help! |
Hi, what is the alternative when I need to use literal IP host name, because will make connection/handshake with an IoT device, that have this IP, but not server name? Snippet of the code: //...
//... Out on Terminal: |
Set the hostname to nil. NIOSSL automatically checks for the IP address in the SAN field, so long as that field has type |
Thanks @Lukasa , but I have a IP, example You can write me an example or edit part of my snippet to visualize your suggestion? |
Change: let sslHandler = try NIOSSLClientHandler(context: sslContext, serverHostname: _hostname) To let sslHandler = try NIOSSLClientHandler(context: sslContext, serverHostname: nil) |
I noticed that
validateSNIServerName
is called even when the TLS configuration explicitly disables hostname validation withcertificateVerification
set to.noHostnameVerification
. I'm not too familiar with this library but this seems like a bug to me?This pr adds a check to
NIOSSLClientHandler.swift
andUniversalBootstrapSupport.swift
to skipvalidateSNIServerName()
if the TLS context hascertificateVerification
set to.noHostnameVerification
. It also adds a test case which fails without this check and now passes.Hope this change makes sense! Please let me know if there is anything I've missed or can improve.