If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Redirect to a link that results in a cert error leaves the redirecting URL in the address bar

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::Browser
P2
normal
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: briansmith, Unassigned)

Tracking

unspecified
Bug Flags:
sec-review +

Firefox Tracking Flags

(blocking-basecamp:-)

Details

(Whiteboard: c=browser u=user)

Attachments

(1 attachment)

(In reply to Antonio Manuel Amaya Calvo from bug 769178 comment #7)
> Dunno about blocker or not. I just lost an hour debugging something related
> to this error though. Turns out that if you connect to a URL with a correct
> certificate (say https://server.com) that then redirects you to a URL with
> an incorrect certificate (trusted CA, bad name, say https://m.server.com)
> you get the same 'URL invalid'... and when you click on the address bar it
> shows https://server.com, NOT https://m.server.com which was the one that
> actually failed.
> 
> Probably not blocking, definitely irritating.

Antonio, please share a URL that demonstrates this problem, if you have one.

Also, is this B2G-specific or does it happen in Firefox Desktop and/or Firefox Mobile too?
I got this on an internal server, which now doesn't fail since we replaced the cert with a correct one. The setup that failed is a server with two virtual servers running on the same ip (but with different DNS names). Both virtual servers had  the same certificate configured which was valid for only one address (now it's valid for both address and don't fail anymore). 

When you access the server as https://server.com with a mobile browser it redirects you to https://m.server.com (I'm almost but no completely sure that the redirection is done by JavaScript, I can confirm that on Monday). When that happens on B2G you get an invalid URL error... And no way to know which URL is failing. 

Haven't checked on Firefox for Android, but I don't think the desktop is affected since I'm guessing I would have got the invalid certificate page which lets you examine the certificate that fails the verification. Again, I can confirm that on Monday if it's needed.
Since the target channel didn't call OnStartRequest that would lead to OnLocationChange, the URL is not updated, since we didn't render the page.  This could be an expected behavior.

CC'ing bz to confirm/refute this.

However, I really have to say we should change this behavior for few cases.
Indeed.  In general, we want the url bar to match the content being shown in the browser tab, so no navigation means no location change.
OK, I was wrong.  When the target page of the redirect has wrong certificate, the URL must be updated, since OnStartRequest *IS* called from the target load, however state of the channel is a failure.

So, if the new URL did not appear, it was a bug.


I made a simple local test for cases (current m-c):
1. redirect via regular http header
2. redirect by JS from head script
3. redirect by JS from onload
4. redirect by JS from onload+timeout

All redirect from a valid ssl site to a site with the same cert but not matching domain (invokes an error page).

They all correctly shows the target URL in the address bar + the error page.
Comment 4 tests were run in Firefox.
Created attachment 644976 [details]
CA for the test URL

CA for the URL I used to test it
Continuation to comment 6. I've set up a test URL at https://sigsegv.es . The CA used to sign the certificate is on C6 attachment.

The code for https://sigsegv.es has a simple Javascript redirect to 
https://sigsegv-m.es. The cert in sigsegv.es is correct (if you trust the CA, that is), but the cert in sigsegv-m.es isn't (is the same server and the same cert in fact).

When accessing from desktop firefox, the behavior is correct. The URL bar changes to show https://sigsegv-m.es and then it gives a certificate error. 

When using the browser in B2G, though, I get an 'The address isn't valid' error, but when I click on the URL bar the address that it shows is the one I wrote (https://sigsegv.es) instead of the one that actually gives an error (https://sigsegv-m.es).

https://sigsegv.es/index2.html doesn't have a redirection, when I access that on the B2G browser (after adding the CA cert to the browser certificate db) I don't get any error.
Moving to a different product and component based on comment 7.
Component: Security: UI → Gaia::Browser
Product: Core → Boot2Gecko
Justin, do you think this might be caused by gecko not firing the mozbrowserlocationchange event in these circumstances?
(In reply to Ben Francis [:benfrancis] from comment #9)
> Justin, do you think this might be caused by gecko not firing the
> mozbrowserlocationchange event in these circumstances?

That could be.  It would be easy for you to test...
blocking-basecamp: --- → ?
Ben how bad it is to not have this on V1
blocking-basecamp: ? → -
Flags: needinfo?(ben)
It would be nice to get security input on this.

I'm wondering if it might be a wider issue with all kinds of errors preventing the address bar getting updated. It would need further investigation...
Flags: needinfo?(ben)
Keywords: sec-review-needed
sec-review-needed (kw) is being depricated for sec-review? (flag)
asking :pauljt as he has done much of the FxOS review work
Flags: sec-review?(ptheriault)
Flags: needinfo?(ptheriault)
Keywords: sec-review-needed
In terms of rating this bug, I am  more concerned about the spurious error message ("the address is invalid" ie bug 796362 and similar) than the behavior exhibited here - its annoying to debug, but I can't think of an exploitation case.
Flags: sec-review?(ptheriault)
Flags: sec-review+
Flags: needinfo?(ptheriault)
Priority: -- → P2
Whiteboard: c=browser u=user
I cant reproduce this failure any more

http://junk.arandomurl.com/invalid-ssl-redirect.html
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.