Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title
Josh Cooper commented on PUP-10154
Re: Detect connection errors when using TLS 1.3 and using post-handshake authentication
It's now possible to configure puppetserver to use TLS 1.3:
[root@prim-skepticism ~]# yum install java-11-openjdk
[root@prim-skepticism ~]# yum install java-11-openjdk-devel
[root@prim-skepticism ~]# grep JAVA_BIN /etc/sysconfig/puppetserver
JAVA_BIN="/usr/lib/jvm/java-11/bin/java"
[root@prim-skepticism ~]# cat /etc/puppetlabs/puppetserver/conf.d/webserver.conf
webserver: {
access-log-config: /etc/puppetlabs/puppetserver/request-logging.xml
client-auth: want
ssl-host: 0.0.0.0
ssl-port: 8140
ssl-protocols: [TLSv1.3]
cipher-suites: [TLS_AES_128_GCM_SHA256]
}
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10154 Detect connection errors when using TLS 1.3 and using post-handshake authentication Change By: Josh Cooper Epic Link: PUP- 8550 10402 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337392.1575326015000.25207.1585611900067%40Atlassian.JIRA.
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title Josh Cooper commented on PUP-10154 Re: Detect connection errors when using TLS 1.3 and using post-handshake authentication Puppetserver doesn't support TLSv1.3: $ openssl s_client -connect red-overhead.delivery.puppetlabs.net:8140 -tls1_3 CONNECTED(0005) 4754687424:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 260 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title Jorie Tappa commented on PUP-10154 Re: Detect connection errors when using TLS 1.3 and using post-handshake authentication We need to ask Server what TLS protocols Puppet Server supports in a fresh install, and determine from there how to proceed with this. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337392.1575326015000.1528.1580149080096%40Atlassian.JIRA.
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title
Josh Cooper updated an issue
Puppet / PUP-10154
Detect connection errors when using TLS 1.3 and using post-handshake authentication
Change By:
Josh Cooper
Prior to TLS 1.3, the client always sends it its certificate (if it has one) during the TLS handshake. As a result, the {{OpenSSL::SSL::SSLSocket#connect}} method only returns success if the server accepted our client cert (or we didn't have one) . This way we can differentiate between connection errors and other types of errors, like HTTP 302, when processing our server list, finding a suitable server using SRV, etc.When using TLS 1.3, the client cert *may* be sent after the server completes its side of the TLS handshake. This is referred to as post handshake authentication. This means the client won't know if the server accepted its client cert until after {{SSLSocket#connect}} returns and we try to send application data. If the server rejected our cert, then we'll get a {{ECONNRESET}}.It also appears TLS 1.3 can send the client during the handshake (it was on by default in openssl 1.1.0, but [changed to opt-in in 1.1.1|https://github.com/openssl/openssl/pull/6938]) to reduce the number of TLS packages that are needed to connect/resume. It appears ruby hardcodes the use of {{post_connection_auth}}. See [https://github.com/ruby/openssl/pull/239] However that version of ruby-openssl hasn't been promoted into any branch of ruby yet.If there was a way to set disable that extension via {{Net::HTTP}} then we wouldn't need to account for the different protocol behaviors.
Add Comment
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10154 Detect connection errors when using TLS 1.3 and using post-handshake authentication Change By: Josh Cooper Sprint: Coremunity Grooming Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337392.1575326015000.53634.1575477600353%40Atlassian.JIRA.
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10154 Detect connection errors when using TLS 1.3 and using post-handshake authentication Change By: Josh Cooper Sprint: Coremunity Grooming Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.337392.1575326015000.53631.1575477600340%40Atlassian.JIRA.
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title
Josh Cooper updated an issue
Puppet / PUP-10154
Detect connection errors when using TLS 1.3 and using post-handshake authentication
Change By:
Josh Cooper
Prior to TLS 1.3, the client always sends it certificate during the TLS handshake. As a result, the {{OpenSSL::SSL::SSLSocket#connect}} method only returns success if the server accepted our client cert. This way we can differentiate between connection errors and other types of errors, like HTTP 302, when processing our server list, finding a suitable server using SRV, etc.When using TLS 1.3, the client cert *may* be sent after the server completes its side of the TLS handshake. This is referred to as post handshake authentication. This means the client won't know if the server accepted its client cert until after {{SSLSocket#connect}} returns and we try to send application data. If the server rejected our cert, then we'll get a {{ECONNRESET}}.It also appears TLS 1.3 can send the client during the handshake (it was on by default in openssl 1.1.0, but [changed to opt-in in 1.1.1|https://github.com/openssl/openssl/pull/6938]) to reduce the number of TLS packages that are needed to connect/resume. It appears ruby hardcodes the use of {{post_connection_auth}}. See [https://github.com/ruby/openssl/pull/239] However that version of ruby-openssl hasn't been promoted into any branch of ruby yet. If there was a way to set disable that extension via {{Net::HTTP}} then we wouldn't need to account for the different protocol behaviors.
Add Comment
This me
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title
Josh Cooper updated an issue
Puppet / PUP-10154
Detect connection errors when using TLS 1.3 and using post-handshake authentication
Change By:
Josh Cooper
Prior to TLS 1.3, the client always sends it certificate during the TLS handshake. As a result, the {{OpenSSL::SSL::SSLSocket#connect}} method only returns success if the server accepted our client cert. This way we can differentiate between connection errors and other types of errors, like HTTP 302, when processing our server list, finding a suitable server using SRV, etc.When using TLS 1.3, the client cert *may* be sent after the server completes its side of the TLS handshake. This is referred to as post handshake authentication. This means the client won't know if the server accepted its client cert until after {{SSLSocket#connect}} returns and we try to send application data. If the server rejected our cert, then we'll get a {{ECONNRESET}}.It also appears TLS 1.3 can send the client during the handshake (it was on by default in openssl 1.1.0 , but prefers [changed to send it after, opt-in in 1.1.1|https://github.com/openssl/openssl/pull/6938]) to reduce the number of TLS packages that are needed to connect/resume. It appears ruby hardcodes the use of {{post_connection_auth}}. See [ https://github.com/ruby/openssl/pull/239 ] If there was a way to set disable that extension via {{Net::HTTP}} then we wouldn't need to account for the different protocol behaviors.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e
Jira (PUP-10154) Detect connection errors when using TLS 1.3 and using post-handshake authentication
Title: Message Title Josh Cooper created an issue Puppet / PUP-10154 Detect connection errors when using TLS 1.3 and using post-handshake authentication Issue Type: Bug Assignee: Unassigned Created: 2019/12/02 2:33 PM Priority: Normal Reporter: Josh Cooper Prior to TLS 1.3, the client always sends it certificate during the TLS handshake. As a result, the OpenSSL::SSL::SSLSocket#connect method only returns success if the server accepted our client cert. This way we can differentiate between connection errors and other types of errors, like HTTP 302, when processing our server list, finding a suitable server using SRV, etc. When using TLS 1.3, the client cert may be sent after the server completes its side of the TLS handshake. This is referred to as post handshake authentication. This means the client won't know if the server accepted its client cert until after SSLSocket#connect returns and we try to send application data. If the server rejected our cert, then we'll get a ECONNRESET. It also appears TLS 1.3 can send the client during the handshake, but prefers to send it after, to reduce the number of TLS packages that are needed to connect/resume. It appears ruby hardcodes the use of post_connection_auth. See https://github.com/ruby/openssl/pull/239 If there was a way to set disable that extension via Net::HTTP then we wouldn't need to account for the different protocol behaviors. Add Comment
