runtime
runtime copied to clipboard
dotnet
Changing SSL Certificate Without Closing Connection
i want to change SSL Certificate (HTTPS)(both Client and Server Certificate) Without Closing Connection in C#.
i can use TcpClient/TcpListener (Socket) with SSLStream but if i use that, i need to implement a lot of http mechanism.
Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.
Issue Details
i want to change SSL Certificate (HTTPS)(both Client and Server Certificate) Without Closing Connection in C#.
i can use TcpClient/TcpListener (Socket) with SSLStream but if i use that, i need to implement a lot of http mechanism.
| Author: | KFKMan |
|---|---|
| Assignees: | - |
| Labels: |
|
| Milestone: | - |
what is your scenario and platform @KFKMan ? The server needs to ask to start with. With TLS 1.2 and bellow that would trigger renegotiation. On TLS 1.3 PHA should kick in. This should work if no certificate was previously set but I'm not sure if/how that would work if certificate was already selected.
I don't think there is good mechanism to change it for server.
This issue has been marked needs-author-action and may be missing some important information.
what is your scenario and platform @KFKMan ? The server needs to ask to start with. With TLS 1.2 and bellow that would trigger renegotiation. On TLS 1.3 PHA should kick in. This should work if no certificate was previously set but I'm not sure if/how that would work if certificate was already selected.
I don't think there is good mechanism to change it for server.
1- Create HTTPS Connection 2- Get String Data From Server With This Connection 3- Change Certificate for Both Server And Client 4- Get New String Data 5- .... Other Parts
i'm creating new HTTPS based Protocol for Security. We know SSL/TLS is not enough in current direct connection mechanism (like signing system, centrally connected CA's.. and a lot of more).
i think HttpClient/WebClient can be more customizable. For PHA maybe a port can be added. Like Custom PHA Store classes which is storing PHA datas and which has a Add/Remove functions like a ICache interface.
Target Platform => All Platforms
i'm creating new HTTPS based Protocol for Security.
.... yeahhhh, I dunno about that.
You might be creating a TCP-Based protocol (of which HTTP/S is already one), but almost all such protocols just re-use TLS on the TCP pipe, because security is hard and missing something can be catastrophic. If you just do a TCP-based protocol you can concentrate on just that part, and leave the hard stuff to somebody else.
We know SSL/TLS is not enough in current direct connection mechanism (like signing system, centrally connected CA's.. and a lot of more).
TLS is fine, and under certain setups is completely uncrackable for the actual communication. Yes, there are issues with the ecosystem, but you can't solve this with any new security protocol, because it will have the exact same problems.
Note that the "traditional" way to solve updating or changing the cert would be to just close the connections and restart them. You need to be able to handle such a situation anyways because network connections can always go down, so the fact that the cert also changes isn't much of a problem.
Your protocol may need to pass some sort of message about updating the cert, but that depends on other external factors.
i'm creating new HTTPS based Protocol for Security.
.... yeahhhh, I dunno about that.
You might be creating a TCP-Based protocol (of which HTTP/S is already one), but almost all such protocols just re-use TLS on the TCP pipe, because security is hard and missing something can be catastrophic. If you just do a TCP-based protocol you can concentrate on just that part, and leave the hard stuff to somebody else.
We know SSL/TLS is not enough in current direct connection mechanism (like signing system, centrally connected CA's.. and a lot of more).
TLS is fine, and under certain setups is completely uncrackable for the actual communication. Yes, there are issues with the ecosystem, but you can't solve this with any new security protocol, because it will have the exact same problems.
Note that the "traditional" way to solve updating or changing the cert would be to just close the connections and restart them. You need to be able to handle such a situation anyways because network connections can always go down, so the fact that the cert also changes isn't much of a problem. Your protocol may need to pass some sort of message about updating the cert, but that depends on other external factors.
First of all, thanks for answer
Yes, Http/Https is working on Tcp Socket. But if i use Socket, i will need to implement all http/https stuffs from compression to state messages.. it is not a good idea. if i will implement that It won't be connected to .net so it won't be able to receive updates.
i don't want to close connection because when multiple request sended it will be confuse.
Yes, i know connection can be closed. i only want to implement non-close connection for a little part.
if connection close create new connection. Yes, but it is a main data which is needed. if connection closed in main area try again from first.
And no, security can be fixable with Self Signed Certificates... (With one of a unattached Trusted Certificate, Certificate Pinning...)
On current system (default TLS) normal hackers can't be break it easily. With my system it can't be break easily with ecosystem too (ecosystem can Man in the middle attack at users first request to the server and yes it is can't prevented but on the other requests it can be prevented).
i want a port for Httpclient/WebClient to accessing SSLStream and customizable PHA Stores....
And no, security can be fixable with Self Signed Certificates... (With one of a unattached Trusted Certificate, Certificate Pinning...)
On current system (default TLS) normal hackers can't be break it easily. With my system it can't be break easily with ecosystem too (ecosystem can Man in the middle attack at users first request to the server and yes it is can't prevented but on the other requests it can be prevented).
There's two primary concerns with the current TLS ecosystem:
- Problems with checking revocation of certificates.
- Rogue CAs issuing malicious certs.
There isn't really a protocol-level way to fix these problems - they're best handled at the application or maintainer level.
The one people are usually most concerned about is 2 (which in some edge cases may allow for MITM), but:
- The CAs generally have recognized this problem, and implemented a system to make their actions more transparent (mostly to each other and some major stakeholders).
- The "trivial" fix is to reduce the number of CAs you consider trusted (potentially to just your own root), however this restricts the number of previously uncontacted parties you can interact with (this is obviously more of a problem for browsers, not so much on restricted deployments).
Again, you cannot fix this with a new protocol, HTTP or otherwise.
It sounds like you're thinking of some combination of:
- Restricting the number of root CAs
- Pinning the first cert encountered.
... It's probably telling that the equivalent functionality for 2, HPKP, is deprecated and removed.....
That said, neither of those are really appropriate for a protocol - they're best handled at the application/maintainer level.
Yes, Http/Https is working on Tcp Socket. But if i use Socket, i will need to implement all http/https stuffs from compression to state messages.. it is not a good idea. if i will implement that It won't be connected to .net so it won't be able to receive updates.
Then you're limited to what HTTP allows you to do. This may show up in some "application layer" protocols, but generally most useful new protocols want to go down a layer to set up their own compression and state messages (ie, that's the entire point). If you ignore your other security issues and just use "vanilla" HTTP as your transport mechanism, key updates should be handled transparently for you (well, assuming C# implements the relevant standards, anyhow).
i don't want to close connection because when multiple request sended it will be confuse.
Yes, i know connection can be closed. i only want to implement non-close connection for a little part.
I have bad news for you. When doing any network communication you MUST assume that the connection will go down at the most problematic time. Including when you have multiple requests pending, partially transmitted, partially received, right in the middle of any certificate update, in the middle of uploading a large file, etc.
The benefit of designing your own application protocol is that you have the freedom to design around the problem. If for some reason the underlying protocols don't transparently handle certificate update, I would probably (given you're probably writing a server: - Finish all outstanding requests - Send all new requests _on the same connection_/TCP Session [HTTP 503 (Service Unavailable)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503) with some short retry-after period. - Drop the connection - Allow new requests to use the new certificate.
If you're thinking of using something like Server Sent Events, send a message to the client. Client should stop sending new data messages and instead drop the connection.
Alternatively, design a heartbeat/status operation, where one of the returned results can be "please reconnect". Client again should drop the connection and reconnect.
The problem of TLS is being affiliated with a central structure. NSA, MIT and a lot of organisation have certificate datas. it's not only about that. TLS signatures can easily copyable. And it's removing your freedom on web, you become addicted to CA's
i want to add my custom unofficial TLS Version which require not closed connection on certificate change. Yes connection can be down at any time. TLS and a lot of protocol need not closed connection too (if any connection error on main data it will send reconnect request it is also supported in my protocol).
i only want to get 2 or more certificate without closing Connection. You can think that as 2 layer TLS (it's not that, it's example for to understand why it is necessary).
The problem of TLS is being affiliated with a central structure. NSA, MIT and a lot of organisation have certificate datas. it's not only about that. TLS signatures can easily copyable. And it's removing your freedom on web, you become addicted to CA's
.... No. Just, no.
TLS, as a protocol, is actually independent of any CA, and deals only with "raw" certificates. Certificate stores are an application feature. The NSA does not have most certificate private keys, and in fact most companies go to great lengths to ensure even they themselves cannot extract or copy private data as a general security mitigation (usually via dedicated hardware). CAs do not have private keys for the certificates they sign, and instead only sign public data. The NSA is often involved in the design or vetting of encryption algorithms, however final design and implementation is not something they control (and is usually an international effort). CAs solve a very real-world practical problem, which is figuring out if somebody you haven't talked to before is who they claim to be. There is no "addiction" here. You're free to remove their root certificates from your devices (or add your own), you're just going to find it extremely hard to talk to others. All commonly proposed solutions tend to be some form of "CAs, but with extra steps".
i want to add my custom unofficial TLS Version which require not closed connection on certificate change.
TLS is below HTTP, so which is it? Also, both TLS 1.2 and TLS 1.3 appear to already have key update mechanisms in place, so (assuming C# or your webserver implement it), there isn't anything you need to do.
Perhaps the better question to ask would be, "What actual big-picture problem are you trying to solve?" What aspect makes you think you need to design and implement an entire protocol, as opposed to using an existing one? Why is it important that the connection not go down at all?
How can we trust CA's? Most of the CA's creating certificates self? Example Let's Encrypt creating certificate for us. is can access private key because is created.
And my solution is not a private solution.
TLS independent right because it's protocol. But using TLS in public without Root Certificate (CA) is have a lot of security problem.
My system using a security layer like a 2 layer TLS.
-Create https connection -Get next certificate hash -Change certificate -Check given hash and certificate hash equality .... And a lot of more mechanism.
if connection need to be closed for changing certificate it will accour problems on multiple requests at same time. Server can't be know the step of connection. Maybe it's on the last, middle or first.
How can we trust CA's? Most of the CA's creating certificates self? Example Let's Encrypt creating certificate for us. is can access private key because is created.
CAs do not generate or store private keys, period. You give them your public key (that you give to all visitors), plus a bit of extra info (also public), and they generate a certificate for your server to prove who it is. At no time should your private key leave your infrastructure (and if you have a hardware module, extracting it may not be possible at all).
My system using a security layer like a 2 layer TLS.
Your system solves nothing. The biggest problem you have is that you're assuming you can trust the initial certificate received. If you can't do that, asking for a second certificate doesn't improve things any (because a lying server is in control of the next certificate you receive). If you can trust the original certificate, why aren't you just using that?
If you're thinking of something like per-connection certificates;
- There's no reason to use such a thing. There is no known attack, and each connection is already secured separately during the key negotiation.
- There are established ways to handle such a scheme, most easily by getting your own "intermediate CA" certificate. These certs are common for some business uses, and are most often issued for single domain.
if connection need to be closed for changing certificate it will accour problems on multiple requests at same time. Server can't be know the step of connection. Maybe it's on the last, middle or first.
If, after issuing the new certificate, you expect future "new" connections to use that certificate, there is no functional difference. It would be more secure and robust to explicitly support such an ability. The ability to change the certificate on the live connection should be viewed as a nice-to-have, not as a fundamental requirement for a properly functioning application.
How can we trust CA's?
X509ChainPolicy.CustomTrustStore
With .NET 8 you can handle that through SslClientAuthenticationOptions.CertificateChainPolicy and SocketsHttpHandler.SslOptions
you can take a look at https://github.com/dotnet/runtime/blob/5d123f164a7a608dd655bdbdf997f1189def9445/src/libraries/System.Net.Http/tests/FunctionalTests/SocketsHttpHandlerTest.cs#L4176
In general, you can bypass all standard validation and implement whatever you want. But as far as flow, you would still depends on OS to do the protocol e.g. schannel and OpenSSL (as SslStream is only wrapper not separate implementation)
How can we trust CA's? Most of the CA's creating certificates self? Example Let's Encrypt creating certificate for us. is can access private key because is created.
CAs do not generate or store private keys, period. You give them your public key (that you give to all visitors), plus a bit of extra info (also public), and they generate a certificate for your server to prove who it is. At no time should your private key leave your infrastructure (and if you have a hardware module, extracting it may not be possible at all).
My system using a security layer like a 2 layer TLS.
Your system solves nothing. The biggest problem you have is that you're assuming you can trust the initial certificate received. If you can't do that, asking for a second certificate doesn't improve things any (because a lying server is in control of the next certificate you receive). If you can trust the original certificate, why aren't you just using that?
If you're thinking of something like per-connection certificates;
- There's no reason to use such a thing. There is no known attack, and each connection is already secured separately during the key negotiation.
- There are established ways to handle such a scheme, most easily by getting your own "intermediate CA" certificate. These certs are common for some business uses, and are most often issued for single domain.
if connection need to be closed for changing certificate it will accour problems on multiple requests at same time. Server can't be know the step of connection. Maybe it's on the last, middle or first.
If, after issuing the new certificate, you expect future "new" connections to use that certificate, there is no functional difference. It would be more secure and robust to explicitly support such an ability. The ability to change the certificate on the live connection should be viewed as a nice-to-have, not as a fundamental requirement for a properly functioning application.
On most of the popular CA's it's creating certificate for you. As you said, there isn't a structure where you create the certificate and then provide public data for a CA to sign.
"You can think that as 2 layer TLS (it's not that, it's example for to understand why it is necessary)."
"At first, the server will have certificates. The first one should be the root certificate so that protection against normal attacks brought by the root certificate can be used. Normally, there is no requirement for the first certificate to be a root certificate. But it is preferred. Now there are 2 modes depending on whether certificate pinning is open or not, when SP1 requests it initially, the server gives it to us. I will delve into those details later, let me briefly go over the modes now.
First, without certificate pinning, here 2 certificates are sufficient. One root and one private. Since there is no pinning, certificates can be changed at any desired time, so 2 certificates are sufficient, one root and one private.
Secondly, with certificate pinning, the hashes of the certificates are kept in cache for a certain period and checked. So if there is a change, the connection is terminated. What if the user wants to change one of the certificates? That's why there should be many certificates here so that when one certificate changes, the certificate can be changed with the approval of the other certificates.
Certificates can be tied to small authorities not tied to root authorities.
Now let's move on to the system, first of all, if certificate pinning is open and there is a cache, the initial steps are skipped and the value of the SS key in the header is set to SPAC1 (I remember it that way) and connected. And their hashes are checked. If the hashes do not match or if the authorities to which the certificates are tied consider the certificate invalid, then the change process will be checked, I will explain that later.
First of all, normally, in the first connection, the value of the SS key in the header is set to SP1. If the server also supports this protocol, it puts the SS key and its corresponding SP1 value in its header. And some information is returned. If certificate pinning is open, it shows whether it is valid for how long, the hash of the next certificate, etc.
Then the server switches to the next certificate without disconnecting the connection. It gives the hash of the next certificate. This process continues until the last certificate is reached. When the last certificate is reached, the connection is completed. And whatever is normally there is displayed. For example, a blog, a news site, etc."
That's my part of protocol document, it's not finished because of that don't worry about SS/SP1 and others.
The handshake occurs before the SSL/TLS connection, followed by the transmission of data. I am changing the certificate based on the connection status. (Main certificate, Intermediate certificates, and End certificate). A sequential change is made from the first certificate to the last certificate. If the connection is interrupted during the certificate change, it needs to start over from the beginning. If it does not start over from the beginning, the server cannot determine which request is in which connection state for simultaneously incoming multiple requests from the same client, so multiple requests from the same client cannot be handled simultaneously.
This system uses the root certificate provided by CAs because it is necessary; otherwise, numerous security issues arise (speaking for a public system). However, it uses this root certificate as the initial step. With this certificate, it provides the hash of the next certificate to the client. This allows the transition to other self-signed certificates. Along with the Certificate Pinning feature, except for the initial request, in subsequent requests (requests where the Certificate Pinning period has not expired), it restricts access from NSA, MIT, and CAs. If the hash of the certificate provided by the server does not match the certificate in the cache, the connection is considered unsafe (there is also a special mechanism for certificate changes), meaning that Man-in-the-Middle attacks are not easily carried out. And since the certificate through which the main data flow passes is not tied to Root CAs, the data flow cannot be intercepted.
.... no, you still haven't really solved the problem, because if you're insistent that it's a problem then it's already a problem, and you've been compromised since the beginning, since you first received whatever initial certificate. You may as well just pin whatever certificate you first receive from a site with standard HTTPS, and not bother with the rest of the mechanism, it will be just as secure. Note that this was effectively what HPKP was doing, and it was deprecated due to potential "lock out" problems.
If you're really concerned, you should pare back to a set of CAs you trust and restrict the set of sites you accept certificates from them for, or explicitly trust a specific set of specific-site certificates, or similar (note that this is all application-level stuff, not protocol level).
At first, the server will have certificates. The first one should be the root certificate so that protection against normal attacks brought by the root certificate can be used.
When we talk about a "root certificate", this is generally understood to be a "root of trust" certificate issued by a CA to themselves, which is used to sign certificates for other sites (leaf certificates). For MiTM attacks like you're worried about, the potential threat is that the CA turns malicious or is compromised and issues a certificate for a site they don't actually control. This has happened, but all major reputable CAs that your browser/OS trusts by default now implement a protocol to help guard against this. In any case, servers of websites do not have "root" certificates in this sense. They only have leaf certificates. There isn't a compelling security reason for them to start doing this handoff dance like you're imagining.
All certificate authorities I know create the certificate for you, so they have access to the certificate data. I gave you an example related to this. Does this mean Let's Encrypt is not safe, but others are safe? I'm not talking about an internal private system here. Ensuring security in an internal private system is simple because potential users are known. Since most certificate authorities create the certificate for us, I consider this as a security vulnerability because they have access to this data. CAs are technically free to do whatever they want; CAs are not an open-source project controlled by everyone. A uninterrupted connection does not lead to a security issue; most systems need to send the initial data fully, otherwise they retry. Here, the problem arises because the connection is closed by software.
It seems like you're not reading or unwilling to understand what I wrote.
You can't fully trust even a system that belongs to you.
How do you trust a system you know nothing about?
You mentioned that CA's sign public data, can you provide an example that is publicly available and signed by CA's?
What you're saying contradicts the mechanism of Let's Encrypt, which is supported by your company and many others. Are you aware of this?
"This has happened" and it can happen again...
Is creating an alternative option bad?
All certificate authorities I know create the certificate for you ... Since most certificate authorities create the certificate for us, I consider this as a security vulnerability because they have access to this data
Certificate, not the private key. All but one piece of information from a CSR is embedded into the public certificate, that you then pass to all visitors of your site (modulo something like billing data info, if any). Everyone has access to this information. The one piece of information that isn't made public is only usable by the CA to authenticate that the CSR came from whoever has the corresponding private key, and does not allow a CA to impersonate a site on its own, or enable any other attacks.
[That's how the system works, period[(https://en.wikipedia.org/wiki/Certificate_authority#Issuing_a_certificate):
A CA issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made available publicly, but kept secret by the end user who generated the key pair.
What you're saying contradicts the mechanism of Let's Encrypt, which is supported by your company and many others. Are you aware of this?
Let's Encrypt doesn't generate/store private certificates. The private key is the thing you have to worry about being stolen, not the certificate, and should only ever be generated/live on the server(s)/infrastructure that uses it (and not, say, a developer machine).
Is creating an alternative option bad?
No. However...
- The system you describe is overly complicated for no appreciable gain in security (or possibly a net loss in security depending on some details). There are existing application-level patterns that can be used to close the holes you can actually do something about. Essentially, what you want is to reinvent HPKP, in mitigation results if not actual details.
- Any system intended for general use (eg, common user web browser) cannot reasonably/practically be closed against the type of attacks you're imagining. Most major providers of such systems (browsers, OSs) already take steps to limit the scope of things like a malicious/compromised CA via monitoring.
- For any restricted-use system, there are far easier ways to mitigate such risks, such as using your own internal private CA, pinned intermediate CA (eg, many mobile applications), or just requiring both parties to have their own self-signed CAs.
While this is fascinating debate, I'm not sure the original ask is quite doable with current platforms. Any thoughts on this @rzikm? I'm inclined to to close it for now.
Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones See info in area-owners.md if you want to be subscribed.
Issue Details
i want to change SSL Certificate (HTTPS)(both Client and Server Certificate) Without Closing Connection in C#.
i can use TcpClient/TcpListener (Socket) with SSLStream but if i use that, i need to implement a lot of http mechanism.
| Author: | KFKMan |
|---|---|
| Assignees: | - |
| Labels: |
|
| Milestone: | - |
I tried to find what RFC says about changing the certificate during connection, while I did not find anything specifically forbidding it, I have some notes:
-
in TLS 1.3, there is no opportunity for server to send new certificate, the
Certificatemessage is sent only during the initial handshake and is not sent ever again during the protocol -
OpenSSL will technically allow PHA multiple times though, and at the surface it seems possible for clients to send different cert each time
-
TLS 1.2 has possibly place for new server cert during renegotiation, but many clients will bail out if server changes certificates (for example Java client). The rationale for that is that it is supposedly not safe but I didn't look into details.
Putting all of that aside, what is even the use case for changing the certificates? The cert is there to prove the identity of the peer to the other side only, it has no other function afterwards.
- if the first certificate is trusted, why a second one is needed? What benefits does it bring?
- if the first certificate is not trusted, do subsequent certificates make the peer more trustworthy?
For now, I don't see enough justification for this feature, and I expect difficulties trying to implement it on all platforms, so I also inclined to close as Won't do.
After reading the entire discussion, it seems to me that you are perceiving there is a problem which, in fact, is not there (the reasoning was IMO sufficiently explained by Clockwork-Muse's comments). Given that the proposed feature is not solving an existing problem and the implementation difficulties. I am closing this for now.
@rzikm - OP's perception of the problems aside, from a quick glance it doesn't appear that SslStream (and thus anything further up the stack) provides any way to set and use a new certificate, meaning that it doesn't support renegotiation or TLS 1.3's PHA, as @wfurt brought up would otherwise be available.
... I am not quickly finding anything that indicates Kestrel can update the certificate via pha on an existing connection, although it can pick up updated certificates (presumably for new connections).
That is, the underlying ask may be legitimate here.
SslStream does support PHA and renegotiation, but you can't currently change the certificate once it is set (I think even the certificate selection callback option will cache the first returned certificate). The important bit of information is that when you specify a client certificate, the client will not send it unless server asks for it (the RFC forbids it).
PHA/renegotiation can be triggered by not specifying SslServerAuthenticationOptions.RequireClientCertificate on the server side and then later calling SslStream.NegotiateClientCertificateAsync. The client SslStream instance will not send the certificate provided in a call to AuthenticateAsClient during the initial connection handshake, but will send it later as server asks for it. However, the method will throw if there is remote certificate already available so the SslStream API cannot be used to trigger PHA/renegotiation multiple times (but it is possible to do so via openssl s_server utility)
That is, the underlying ask may be legitimate here.
It may be legitimate for the client, not server (since it is not possible on protocol-level on TLS 1.3). But implementing this might be complicated and we usually require a legitimate use case for new features, so we know that the feature is actually going to be useful.
Ah, sorry, my bad. I'd thought that PHA was intended to allow the server to update its certificate.
SslStream is a very good class. i'm don't have problem on SslStream.
-
i'm want to close https connection and reconnect. Main tcp connection is needed to be connected. No socket closing actually, only finishing request and creating new request without connection close (On new connection certificate will be changed) (and maybe you can give a access to main tcp connection)
-
i'm want to get access to PHA and other Stores and implement custom Stores
-
i want to use custom algorithms on Encrpytion/Decryption
-
i want a non-close connection mechanism like Socket/WebSocket which can get data in multiple times async.
i want all of them for the Httpclient/WebClient class.
1 => it's for a case where main certificate is knowing from others or a chance for a CA's chances of being hacked. With that system users can create his CA's and connection will be more secure.
2 => i want to add extra data and checks
3 => i'm think no use case needed
4 => maybe WebClient/HttpClient already support that feature
I should probably start with this:
I strongly suggest you avoid trying to implement a custom "better" secure protocol. These things are hard to get right and existing protocols are a result of long collaboration between teams of professionals in cryptography and related fields.
Now to answer some of your questions.
i'm want to close https connection and reconnect. Main tcp connection is needed to be connected. No socket closing actually, only finishing request and creating new request without connection close (On new connection certificate will be changed) (and maybe you can give a access to main tcp connection)
And what additional security does this achieve? As I said, the certificate is only used to validate the identity of the peer. If you trust the first certificate the peer presents, why do you need to validate its identity again?
The certificate itself does not add any additional cryptographic security to the encryption itself, the encryption keys are fully established by some form of Diffie-Hellman Exchange (other schemes are available, but (EC)DHE is the most common) to get a common secret and from there by key derivation scheme specific to the encryption algorithm itself.
i'm want to get access to PHA and other Stores and implement custom Stores
There is no such thing as "PHA Store". Example "stores" (places where certificates are kept) are:
- Root - contains Root certificates of trusted Root CAs (those are self-signed certs which anchor the trust chain)
- Intermediate - for speeding up cert validation (no need to download them if needed) and being able to send those intermediates in handshake if needed
- My (Personal) - to use for authenticating the machine/user itself in a connection
Note that the stores distinction is mainly on Windows, on Linux, both Root and Intermediate certs are usually together in /etc/ssl/certs and "My" store does not exist and the application loads the certificate from wherever it wants to.
Unsure what "implementing custom stores" means, wfurt already mentioned how you can customize which root certificates are to be trusted by supplying custom "Root trust store" in https://github.com/dotnet/runtime/issues/98304#issuecomment-1942111787
i want to use custom algorithms on Encrpytion/Decryption
Adding custom algorithms is not possible from .NET, the algorithm needs to be implemented in the underlying platform library. On Linux, you may be able to affect the algorithm selection via CipherSuitesPolicy.
There should be no need to add new custom algorithms, current ciphers used by TLS 1.3 are deemed secure enough by professional cryptoanalysts.
i want a non-close connection mechanism like Socket/WebSocket which can get data in multiple times async.
Not sure I understand this sentence, but you also mentioned closing and opening new TLS connection on top of unbroken TCP connection. This might already be possible with .NET (SslStream ctor has a parameter whether the underlying stream should be closed when SslStream is closed), however, you need to think about how the other side should know to restart the TLS connection?
i want all of them for the Httpclient/WebClient class.
HttpClient is an abstraction. It even is possible to construct an HttpClient that does not communicate through network (I believe such clients are often used in integration tests where both server and client are both in the same process). Even exposing this on SocketsHttpHandler is problematic because one of the versions (HTTP/3) does not use SslStream or TCP at all (it uses QUIC which is UDP based).
You may have some luck with getting the SslStream instances out of HttpClient by using the SocketsHttpHandler.ConnectCallback.
it's for a case where main certificate is knowing from others or a chance for a CA's chances of being hacked. With that system users can create his CA's and connection will be more secure.
You don’t need any additional features for that. As already mentioned, you can use X509ChainPolicy.CustomTrustStore to configure SslStream to only trust certificates issued by a specific (yours?) CAs. Although this approach opens another can of worms because now you need to make sure the users (safely) get the right CA certificate to anchor the trust chain....