Investigate TLS mutual auth support

[artemredkin]

No description provided.

[Lukasa]

Do you really mean MTLS, or do you mean mutual auth?

[markm77]

Please see this comment: https://forums.swift.org/t/generic-http-client-library-pitch/23341/8.

Yes, mutual TLS for auth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 )

[Lukasa]

Ok, cool: we should probably be consistent in calling that “TLS Mutual Auth” rather than MTLS, which is an ambiguous and uncommon abbreviation.

[markm77]

This requirement comes from a spec which mandates use of TLS mutual auth and refers to it as MTLS. But I can try to avoid that terminology here. : )

[Lukasa]

Yeah, I saw that in the spec! It’s a strange choice. 😂 Regardless, the requirement is reasonable and NIO has the hooks to support it, though there are problems with the interaction with HTTP/2 and connection pooling that need to be considered.

[markm77]

Many thanks Cory. Actually I was referring to another API spec which I'll link by private email for your interest.

[weissi]

@markfinlabs As Cory points out, NIOSSL does support mutual authentication today which works just fine for HTTP/1. I wasn't sure if that was clear from Cory's comment. This is how you would use it:

client

let key = try NIOSSLPrivateKey(file: "/tmp/clientkey/key.pem", format: .pem) { completion in
    completion("password for client's private key".utf8)
}

var tlsConfiguration = TLSConfiguration.forClient()
tlsConfiguration.trustRoots = .file("/tmp/serverkey/cert.pem") // only necessary if the server uses a self-signed cert or a custom CA that isn't trusted by the system. If your server has a real cert, you can delete this line
tlsConfiguration.privateKey = NIOSSLPrivateKeySource.privateKey(key)
tlsConfiguration.certificateChain = [.file("/tmp/otherclientkey/cert.pem")] // same here
tlsConfiguration.certificateVerification = .noHostnameVerification // or `.fullVerification`

And this TLSConfiguration you can just set in Configuration.tlsConfiguration. Therefore swift-nio-http-client will support this just fine today.

server

let key = try NIOSSLPrivateKey(file: "/tmp/serverkey/key.pem", format: .pem) { completion in
    completion("password for server's private key".utf8)
}

var tls = TLSConfiguration.forServer(certificateChain: [.file("/tmp/serverkey/cert.pem")],
                                     privateKey: .privateKey(key))
tls.trustRoots = .file("/tmp/clientkey/cert.pem") // again, only necessary if self-signed or own CA that isn't trusted by the system
tls.certificateVerification = .noHostnameVerification // or `.fullVerification`

let sslContext = try! NIOSSLContext(configuration: tls)

[markm77]

Thanks for this reply, very helpful. We should get a chance to test this next week and I'll report back.

[artemredkin]

@markfinlabs Did you get the chance to test it?

[markm77]

Hi @artemredkin. Sorry to drop the ball on this - our key engineer working on NIO suddenly resigned. I had a go myself to test this tonight but can you tell me something basic which I couldn't find quickly in the docs: how best to generate request.body for a form, i.e. Content-Type == "application/x-www-form-urlencoded" - i.e. is there a helper method to convert name/value pairs?

[artemredkin]

@markfinlabs hi, unfortunately there is no way to do that out of the box. If you need application/x-www-form-urlencoded, you can do the following (given you can convert your parameter values to string representation):

func escape(_ value: String) -> String? {
    return value.addingPercentEncoding(withAllowedCharacters: .urlHostAllowed)
}
func encode(key: String, value: String) -> String? {
    return escape("\(key)=\(value)")
}
func encode(parameters: [String: String]) -> String {
    return parameters.compactMap(encode).joined(separator: "&")
}

request.body = .string(encode(parameters: ["a": "b"]))

[ianpartridge]

Interesting. Do you think we should add convenience API for application/x-www-form-urlencoded? application/json is another which might benefit from some API that accepts a Codable.

[artemredkin]

Good idea, filed #50

[markm77]

Thanks @artemredkin for code sample and just to update you. I tested with the external server (external company) I am working with and unfortunately got sslError([Error: 268435638 error:100000b6:SSL routines:OPENSSL_internal:NO_RENEGOTIATION]) which looking at s4.2 of https://tools.ietf.org/html/rfc5746 may be a problem with the external server and a security feature on your side? npm request worked fine with this server. Do you have any comment on this? I think I'll try to use a different external server (different company) but will take a few days to sort this out.

[weissi]

I think that’s because of this: https://github.com/google/boringssl/blob/master/PORTING.md#tls-renegotiation

Because renegotiation is a mess protocol and security wise, BoringSSL (and therefore nio-ssl) disables it by default. But @Lukasa will know in much more detail and if that’s something we would ever want to support despite the messiness. I’d say definitely not with at least the user asking for it to be turned on.

[markm77]

Thanks @weissi, that makes sense. I'll send you a private reply via the email on your GitHub home page to avoid putting some information into the public domain.

[Lukasa]

We should add renegotiation support, but have it off by default, and require explicit user intervention to enable it. See apple/swift-nio-ssl#110 for tracking that. With that feature in place it should be possible to work around this issue.

[markm77]

Thanks @Lukasa, sounds super helpful as I don't think the server I am interfacing with is likely to change quickly. I will still endeavour to test with another server (different company) this week.

[weissi]

@markfinlabs, @Lukasa implemented this yesterday: apple/swift-nio-ssl#111 . So in theory you can test this today using swift package edit or you'll wait for the swift-nio-ssl version 2.2.0 release which shouldn't be long.

[markm77]

Thanks @weissi, great news. I can wait for v2.2.0 to re-check.

[markm77]

I have now tested with a second server and everything works fine (including server using custom CA). 😀

[artemredkin]

Great news! Thank you for testing this.

[markm77]

No pbs, I'll check the renegotiation support after NIO SSL v2.2.0 is released and report back here.

[markm77]

Just coming back to this for completeness. I successfully used TLS mutual auth with the original server I had a problem with using these options:

                tlsConfiguration.certificateVerification = .none
                tlsConfiguration.renegotiationSupport = .once

So thanks for your efforts here everyone.

[ozshabat]

Hey @weissi this issue is related to a TLS authentication. Can you help me with that?