You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The initial implementation of the plugin in #2613 ignores all TLS certificates by hardcoded default. This practice is very bad from a security standpoint.
Describe the solution you'd like
Really, the default should be to always verify certificates.
An option to disable verification should be added to the HTTP API management profile (once #3147 is merged).
Someone has also suggested that there should be an option to pin a specific certificate for a specific device. This is, IMHO, complex enough that it warrants a separate issue (does the pinned cert belong in a management profile or an individual netbox attribute?)
Describe alternatives you've considered
Leave things as they are.
Other considerations
It is unclear whether a Palo Alto REST API uses SNI. The current paloaltoarp plugin does not seem to use SNI, which causes it to fail a TLS connection to an HTTPS server that expects an SNI exchange to select the correct certificate by hostname. This happens even when there is no verification going on from the ipdevpoll plugin. I.e. how to ensure SNI is supported needs to be considered when implementing this.
Example of a non-SNI HTTPS request:
$ openssl s_client -host localhost -port 443CONNECTED(00000003)140336571057472:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1562:SSL alert number 80---no peer certificate available---No client certificate CA names sent---SSL handshake has read 7 bytes and written 283 bytesVerification: OK---New, (NONE), Cipher is (NONE)Secure Renegotiation IS NOT supportedCompression: NONEExpansion: NONENo ALPN negotiatedEarly data was not sentVerify return code: 0 (ok)---
Example of the same request, SNI-enabled:
openssl s_client -host localhost -port 443 -servername localhostCONNECTED(00000003)depth=2 CN = Caddy Local Authority - 2024 ECC Rootverify return:1depth=1 CN = Caddy Local Authority - ECC Intermediateverify return:1depth=0 verify return:1---Certificate chain 0 s: i:CN = Caddy Local Authority - ECC Intermediate 1 s:CN = Caddy Local Authority - ECC Intermediate i:CN = Caddy Local Authority - 2024 ECC Root---Server certificate-----BEGIN CERTIFICATE-----MIIBvjCCAWSgAwIBAgIRAP2+bQ89EavdGqy3DKJBfjswCgYIKoZIzj0EAwIwMzExMC8GA1UEAxMoQ2FkZHkgTG9jYWwgQXV0aG9yaXR5IC0gRUNDIEludGVybWVkaWF0ZTAeFw0yNDEyMDUxMzEzMzRaFw0yNDEyMDYwMTEzMzRaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASgeTy1+3mCqQ6dnmSXKs4Aj8+I6+vZkVk05Ns+HUxeQuwsvDrBqHsadDEPWl2SROIjx15MfE91uufcjs8SF+L4o4GLMIGIMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHQYDVR0OBBYEFB6pywMmTG/CRZsjSiXLN+OSLQZlMB8GA1UdIwQYMBaAFA+K26VWsAprLB/hqIT8u1YeXdmvMBcGA1UdEQEB/wQNMAuCCWxvY2FsaG9zdDAKBggqhkjOPQQDAgNIADBFAiB88tWPDGCTeT3rYrW0H7mhpcsMsec1Yunf9uvMWChreQIhANYkg6u0Iw8V0AKh3Hz6e90RdMLP4nXPKsgbmqEMyPSj-----END CERTIFICATE-----subject=issuer=CN = Caddy Local Authority - ECC Intermediate---No client certificate CA names sentPeer signing digest: SHA256Peer signature type: ECDSAServer Temp Key: X25519, 253 bits---SSL handshake has read 1268 bytes and written 365 bytesVerification: OK---New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256Server public key is 256 bitSecure Renegotiation IS NOT supportedCompression: NONEExpansion: NONENo ALPN negotiatedEarly data was not sentVerify return code: 0 (ok)------Post-Handshake New Session Ticket arrived:SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_128_GCM_SHA256 Session-ID: 9F4AF20489B438DB411A9A60EAD2D8C3DF119736FA4A842C3B36E0D8D6CAA786 Session-ID-ctx: Resumption PSK: B77E1FEE85A2CD28288CDBDAE18F7AD07E76F777131120AEAEEC27B66979A53A PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 604800 (seconds) TLS session ticket: 0000 - 81 4d 9f da cd 1c 6d ad-6e 93 22 da a2 23 f1 dc .M....m.n."..#.. 0010 - c9 65 27 1e 41 fc 5c bb-ce 06 a2 ef 6a d3 5a db .e'.A.\.....j.Z. 0020 - 2e 63 ab 4b f9 7d c2 b3-a4 9e 62 a6 17 9b 38 e5 .c.K.}....b...8. 0030 - e5 8a 73 2f d1 3b 80 3d-9f 2d 9d 48 d1 57 83 df ..s/.;.=.-.H.W.. 0040 - bd 86 35 51 c3 8e a3 a7-fb c4 9d fa 85 20 70 46 ..5Q......... pF 0050 - 93 ae f3 73 c9 14 ef 22-15 30 9d ae 8c 1b a8 37 ...s...".0.....7 0060 - 56 78 ab d4 0c 5c 6b a9-12 Vx...\k.. Start Time: 1733410820 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0---read R BLOCK^C
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The initial implementation of the plugin in #2613 ignores all TLS certificates by hardcoded default. This practice is very bad from a security standpoint.
Describe the solution you'd like
Really, the default should be to always verify certificates.
An option to disable verification should be added to the HTTP API management profile (once #3147 is merged).
Someone has also suggested that there should be an option to pin a specific certificate for a specific device. This is, IMHO, complex enough that it warrants a separate issue (does the pinned cert belong in a management profile or an individual netbox attribute?)
Describe alternatives you've considered
Leave things as they are.
Other considerations
It is unclear whether a Palo Alto REST API uses SNI. The current
paloaltoarp
plugin does not seem to use SNI, which causes it to fail a TLS connection to an HTTPS server that expects an SNI exchange to select the correct certificate by hostname. This happens even when there is no verification going on from the ipdevpoll plugin. I.e. how to ensure SNI is supported needs to be considered when implementing this.Example of a non-SNI HTTPS request:
Example of the same request, SNI-enabled:
The text was updated successfully, but these errors were encountered: