-
Notifications
You must be signed in to change notification settings - Fork 5.3k
avoid allocating collection for intermediate certificates #68188
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
Conversation
|
Tagging subscribers to this area: @dotnet/ncl, @vcsjones Issue DetailsThere are actually two collection we will save in this change for each TLS handshake: Current code always allocates The second collocation comes surprisingly from if (_chainPolicy != null && _chainPolicy.CustomTrustStore != null)does not really work well with public X509Certificate2Collection CustomTrustStore => _customTrustStore ??= new X509Certificate2Collection();
|
rzikm
left a comment
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.
LGTM, modulo comments.
src/libraries/Common/src/Interop/Windows/SChannel/UnmanagedCertificateContext.IntPtr.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/CertificateValidationPal.cs
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/CertificateValidationPal.cs
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/CertificateValidationPal.Android.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/CertificateValidationPal.OSX.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/CertificateValidationPal.Unix.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/CertificateValidationPal.Windows.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/Security/SecureChannel.cs
Show resolved
Hide resolved
| X509Certificate2Collection remoteCertificateStore = | ||
| UnmanagedCertificateContext.GetRemoteCertificatesFromStoreContext(certHandle); | ||
| X509Certificate2Collection remoteCertificateStore = new X509Certificate2Collection(); | ||
| UnmanagedCertificateContext.GetRemoteCertificatesFromStoreContext(certHandle, remoteCertificateStore); |
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.
| UnmanagedCertificateContext.GetRemoteCertificatesFromStoreContext(certHandle, remoteCertificateStore); | |
| UnmanagedCertificateContext.GetRemoteCertificatesFromStoreContext(certHandle, remoteCertificateStore); |
* avoid allocating collection for intermediate certificates * fix NRE for custom trust * feedback from review
There are actually two collection we will save in this change for each TLS handshake:
Current code always allocates
X509Certificate2Collectionto store intermediate certificates from handshake just to add all of them to X509Chain before validation. This change fixes the internal API so that we allocate X509Chain as needed and we add any intermediate certificates to it directly without need to allocate extra collection. (using ref X509Chain?)The second collocation comes surprisingly from
nullcheck:does not really work well with
CustomTrustStorewill never benulland the check will allocate in typical case.