Breaking SSL changes in Chrome 79 update AGAIN
I appreciate that Google are trying to force the web to be more secure but the frequent updates continue to break things that have worked for ages.
Of course, you could argue that we should have done things correctly to begin with but part of the reason we don't is that we don't have to! For example, if two machines are already on a virtual network isolated from the rest of the world, you could configure firewalls between them, but you don't have to.
Likewise, when we run IIS express for our functional tests on localhost, the certificate that IIS installs is self-signed, which is all you can do when you connect to localhost. Up until version 79, Chrome didn't have a problem with the following scenario:
https://localhost/invalidcert/ => 302 http://samesite/over/http
It simply didn't check the certificate that came back because it was about to redirect. Now it does not do this. You instead get the "not trusted" page.
Now sure, what they do now makes sense, otherwise a MITM could provide a false 302 with an invalid cert but I can't find this change announced anywhere, the first thing I know is that our fragile functional tests have all started failing for no obvious reason and spending hours of my time trying to work out what changed.
I had to use a workaround by downgrading to Chrome 78 and disabling the updater since I cannot work out how they expect this scenario to work. The only way it would work, I guess, would be setting up domain names for local test sites. We could do all of that in IIS (and possibly Express) but it ends up requiring a lot of effort just because Google says so!
So by trying to make things better, you have removed our ability to keep Chrome up to date, which will probably have other effects later on.
(Goes away and sulks)
Of course, you could argue that we should have done things correctly to begin with but part of the reason we don't is that we don't have to! For example, if two machines are already on a virtual network isolated from the rest of the world, you could configure firewalls between them, but you don't have to.
Likewise, when we run IIS express for our functional tests on localhost, the certificate that IIS installs is self-signed, which is all you can do when you connect to localhost. Up until version 79, Chrome didn't have a problem with the following scenario:
https://localhost/invalidcert/ => 302 http://samesite/over/http
It simply didn't check the certificate that came back because it was about to redirect. Now it does not do this. You instead get the "not trusted" page.
Now sure, what they do now makes sense, otherwise a MITM could provide a false 302 with an invalid cert but I can't find this change announced anywhere, the first thing I know is that our fragile functional tests have all started failing for no obvious reason and spending hours of my time trying to work out what changed.
I had to use a workaround by downgrading to Chrome 78 and disabling the updater since I cannot work out how they expect this scenario to work. The only way it would work, I guess, would be setting up domain names for local test sites. We could do all of that in IIS (and possibly Express) but it ends up requiring a lot of effort just because Google says so!
So by trying to make things better, you have removed our ability to keep Chrome up to date, which will probably have other effects later on.
(Goes away and sulks)