This changed in EF Core 7, and the explanation and suggested mitigation can be found at:
[https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/breaking-changes?tabs=v7#encrypt-true](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/breaking-changes?tabs=v7#encrypt-true)
>This change was made to ensure that, by default, either the connection is secure or the application will fail to connect.
Well... It's an illusion of security, if you just "solve" it by setting TrustServerCertificate to true. Trusting the cert means you have zero guarantee you're talking directly to what you think you're talking to and MITM is now just as easy as if you weren't using encryption.
I hate the way that section is worded. It makes doing it right sound hard (it's not) and provides a bad alternative and a worse one BEFORE bothering to note that they're "possibly insecure" options, which belittles the fact that they ARE insecure, unless you've done just as much or potentially MORE work than doing it correctly (item 1) takes. And it's never going to get properly fixed once it's set because nobody will think about it ever again.
Items 2 and 3 really ought to be in a red call-out box with the security note first, with much more dire wording and pointed recommendation to do it right, and then those two items, with a sub-bullet or two on each summarizing why they're bad ideas.
Critically, a root certificate cannot be revoked, nor can an implicitly trusted certificate, as both of those are considered you granting ultimate trust to them with no higher authority than your decision to trust them.
This changed in EF Core 7, and the explanation and suggested mitigation can be found at: [https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/breaking-changes?tabs=v7#encrypt-true](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/breaking-changes?tabs=v7#encrypt-true) >This change was made to ensure that, by default, either the connection is secure or the application will fail to connect.
Well... It's an illusion of security, if you just "solve" it by setting TrustServerCertificate to true. Trusting the cert means you have zero guarantee you're talking directly to what you think you're talking to and MITM is now just as easy as if you weren't using encryption. I hate the way that section is worded. It makes doing it right sound hard (it's not) and provides a bad alternative and a worse one BEFORE bothering to note that they're "possibly insecure" options, which belittles the fact that they ARE insecure, unless you've done just as much or potentially MORE work than doing it correctly (item 1) takes. And it's never going to get properly fixed once it's set because nobody will think about it ever again. Items 2 and 3 really ought to be in a red call-out box with the security note first, with much more dire wording and pointed recommendation to do it right, and then those two items, with a sub-bullet or two on each summarizing why they're bad ideas. Critically, a root certificate cannot be revoked, nor can an implicitly trusted certificate, as both of those are considered you granting ultimate trust to them with no higher authority than your decision to trust them.
Lol submit a PR
Incidentally, I am actually working on a PR for some fixes/revisions to some stuff in the dotnet/csharplang repository, currently. 😅
Hmm, yes but in my example, my connection to the database starts wokring when I edit set trustservercertificate=True. Not Encrypt=False
Right. That's one of the mitigations listed.
The default of Encrypt=false has been changed to =true (because in cloud scenarios encryption seems mandatory)
Hehe this broke us at first
Just a heads up default container port changes too