GNOME Bugzilla – Bug 754706
"Load Anyway" doesn't load
Last modified: 2015-09-22 23:57:57 UTC
Apparently my bank's "3D Secure" facility doesn't work: " Look out! This might not be the real 3dsecure.bpce.fr. When you try to connect securely, websites present identification to prove that your connection has not been maliciously intercepted. There is something wrong with this website’s identification: This website’s identification was not issued by a trusted organization. A third party may have hijacked your connection. You should continue only if you know there is a good reason why this website does not use trusted identification. Legitimate banks, stores, and other public sites will not ask you to do this. " At: https://3dsecure.bpce.fr/dacsissuer/dacspa But the load anyway button doesn't work.
This was stopping me from buying food. Had to use another person's card with another 3D Secure server to not lose the whole cart.
It's an Epiphany bug that the button doesn't work. My best guess is that your web extension is broken. I've heard of this before but never managed to reproduce the issue. If you can reproduce it, can you look for warnings printed on the terminal (which may indicate if the web extension failed to load)? You could also try to debug a bit. (Note: I cannot reproduce the issue.) I think we should probably bring down the UI process if the web extension fails to load, instead of allowing the user to continue with degraded functionality. P.S. Regarding your, it is not sending any chain of trust at all, so you have zero protection against a MITM. Clearly they performed absolutely zero testing on their website and everyone has been clicking through the security warnings, or they tested in a browser that had cached the thawte SHA256 SSL CA certificate, proving yet again that certificate caching is harmful. We need to make it way harder to bypass this screen: bug #744063.
(In reply to Michael Catanzaro from comment #2) > It's an Epiphany bug that the button doesn't work. My best guess is that > your web extension is broken. I've heard of this before but never managed to > reproduce the issue. If you can reproduce it, can you look for warnings > printed on the terminal (which may indicate if the web extension failed to > load)? You could also try to debug a bit. (Note: I cannot reproduce the > issue.) I use the "shared-secondary-process" model, which might explain the problem. > I think we should probably bring down the UI process if the web extension > fails to load, instead of allowing the user to continue with degraded > functionality. > > P.S. Regarding your, it is not sending any chain of trust at all, so you > have zero protection against a MITM. Clearly they performed absolutely zero > testing on their website and everyone has been clicking through the security > warnings, or they tested in a browser that had cached the thawte SHA256 SSL > CA certificate, proving yet again that certificate caching is harmful. We > need to make it way harder to bypass this screen: bug #744063. Sure. But as this is where I would have entered a 2FA password to go with my card details (which was on a trusted page), it would have made that much difference in terms of security even if it was in the clear. Hence my attempt to "load anyway".
(In reply to Bastien Nocera from comment #3) > I use the "shared-secondary-process" model, which might explain the problem. It *shouldn't* matter. Indeed, I still can't reproduce. FYI we added a new gsetting that you might like better, in 74e1ff0dd50afc3450eb494dc3c6f5ac0c00b2f5. Still need to integrate these with the memory pressure handler to get a sane process limit by default, though. > Sure. But as this is where I would have entered a 2FA password to go with my > card details (which was on a trusted page), it would have made that much > difference in terms of security even if it was in the clear. Hence my > attempt to "load anyway". I'm not sure I understand how this works; I'll just caution that giving your 2FA token to the MITM usually leads to bad things :)
(In reply to Bastien Nocera from comment #3) > (In reply to Michael Catanzaro from comment #2) > > It's an Epiphany bug that the button doesn't work. My best guess is that > > your web extension is broken. I've heard of this before but never managed to > > reproduce the issue. If you can reproduce it, can you look for warnings > > printed on the terminal (which may indicate if the web extension failed to > > load)? You could also try to debug a bit. (Note: I cannot reproduce the > > issue.) > > I use the "shared-secondary-process" model, which might explain the problem. Note that now (in master) shared-secondary-process uses multiple web process model with limit == 1.
(In reply to Carlos Garcia Campos from comment #5) > (In reply to Bastien Nocera from comment #3) > > (In reply to Michael Catanzaro from comment #2) > > > It's an Epiphany bug that the button doesn't work. My best guess is that > > > your web extension is broken. I've heard of this before but never managed to > > > reproduce the issue. If you can reproduce it, can you look for warnings > > > printed on the terminal (which may indicate if the web extension failed to > > > load)? You could also try to debug a bit. (Note: I cannot reproduce the > > > issue.) > > > > I use the "shared-secondary-process" model, which might explain the problem. > > Note that now (in master) shared-secondary-process uses multiple web process > model with limit == 1. Still using 3.16 here: epiphany-3.16.2-2.fc22.x86_64 webkitgtk4-2.8.5-2.fc22.x86_64
*** This bug has been marked as a duplicate of bug 748691 ***