Need to allow normal HTTP caching with broken TLS/certificate when --ignore-certificate-errors is specified
Reported by
jriv...@gmail.com,
Jan 11 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. Start up chromium with --ignore-certificate-errors flag 2. Access site with broken certificate 3. Observe chrome will never load cachable HTTPS resources from disk cache What is the expected behavior? With --ignore-certificate-errors flag specified, it should be fine to insecurely cache https data. Presumably a different flag could be added to allow caching if bundling this under --ignore-certificate-errors is objectionable. What went wrong? Chrome doesn't disk cache resources if there is a any problem with the TLS connection or certificate. This is totally resonable for nominal operation but makes development debugging of HTTPS caching a huge pain or nearly impossible. If your answer is get a real certificate, my response is that I'm dubugging the downstream results of an HTTPS connection on my local box and I shouldn't need a commercial certificate for this task. Right now the only way to debug HTTPS caching issues is against a production or semi-production server with a valid cert. I'd rather not debug in production. Did this work before? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: Flash Version: Shockwave Flash 24.0 r0
,
Jan 11 2017
,
Jan 11 2017
This is WorkingAsIntended / ByDesign.
,
Jan 13 2017
I understand this is working as designed, but this is a request to change the design. Question: How is a developer supposed to substitute cachability issues on HTTP vs HTTPS with this design? There is no way for me to troubleshoot issues as to why entities aren't being cached with HTTPS until I reach a production environment with a valid cert. This is a bit crazy.
,
Jan 13 2017
You should either use a real certificate in your development environment (which only requires that you give your dev environment a unique qualified name, such as "staging.example.com" if your real site was "example.com", or "example-staging.com" if you wanted fully distinct), or you generate your own test certificate which you then install/authorize as a root certificate on your device. There are no plans to offer cacheability for requests with TLS errors.
,
Jan 14 2017
What is the reason the cache cant be enabled with a command line flag? If it's for security reasons the whole point of that flag is to disable security features for developers - we know when we're using it we no longer have a secure environment. I'm sure in your environment and/or expertise fixing the cert error is simple and obvious but I've now spent two full days trying to get this working and I can not. I am not a certificate expert. I do not want to be a certificate expert. I suspect I am not alone. Anytime anyone is forced to touch certificates its a roadblock so it ought not be required unless I'm actually deploying a secure service. Why do I have to be a certificate expert to debug cachability problems that should have nothing to do with tls validity? In all other ways I can debug a system over https with a bogus certificate, what is so special about caching? |
|||
►
Sign in to add a comment |
|||
Comment 1 by jriv...@gmail.com
, Jan 11 2017