Closed Bug 457100 Opened 17 years ago Closed 17 years ago

hg https does not work

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
x86
Linux
Type:
task
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: BenB, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

pulling from https://hg.mozilla.org/comm-central/ abort: error: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> This used to work 2-3 weeks ago. https is critical for security to fetch the correct source, see bug 450645. In fact, I can't tell the difference whether this is an attack or just a bad server. An attacker would do exactly this. I don't know whether I can compile the source.
Wouldn't an attack give a cert-mismatch error? Agree that this is v. bad, though. IT: is there nagios coverage of the https service?
Seems to work for me... ~/work/code $hg clone https://hg.mozilla.org/ast destination directory: ast requesting all changes adding changesets adding manifests adding file changes added 273 changesets with 692 changes to 56 files updating working directory 44 files updated, 0 files merged, 0 files removed, 0 files unresolved ~/work/code $
shaver, yes, a stupid attack would. A smart attack would prevent me from using SSL and make me go back to unsecured (http), and do a MITM on that.
(In reply to comment #1) > IT: is there nagios coverage of the https service? Yes, but it was only monitoring one of the two servers that power hg.mozilla.org. I updated the checks appropriately.
(In reply to comment #3) > shaver, yes, a stupid attack would. A smart attack would prevent me from using > SSL and make me go back to unsecured (http), and do a MITM on that. How would any smart attack give you back content without a cert error? That's the part I don't understand, and I'd like to.
I retract and claim the opposite! I was using a system-wide proxy setting without realizing it. Removing it makes it work again. Sorry for the false alarm! INVALID
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
No longer blocks: 450645
In case you're still interested: > How would any smart attack give you back content without a cert error? That's > the part I don't understand, and I'd like to. Assuming the attacker can provoke the error I got, I would not get a cert error, but an entirely failure of the SSL connection, as shown in initial description. I would think that the server is broken, or just not care, and manually fall back to http, to get my work done, like I did now. (Either way, an average user would not be suspicious of an attack.) Now I am on an insecure connection, and you can attack that like any other insecure connection.
The error you got is from hg getting back HTML and trying to read it as hg command stream. You didn't get a failure of the SSL connection; that would look like abort: error: Connection refused or some SSL error, right?
Sure. But if the HTML page came from the proxy, and the attacker can get between me and the proxy? He should be able to fake this error. Also, "a connection refused" would do the same trick. I'd probably go back to http, as would most people, and most would not even be suspicious. (One more reason not to even offer http.) Anyways, not important anymore.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.