146995 - Cannot import CRLs directly via links on a web page

Status: RESOLVED INVALID

(Core Graveyard :: Security: UI, defect)

Description

[Sönke Tesch]

The CRLs from one of Germany's largest CA, TC TrustCenter AG, cannot be imported
via their web page at https://www.trustcenter.de/cgi-bin/CRL.cgi . Upon clicking
on one of the links to the CRLs, Mozilla just displays "Tranfering data.." in
the status bar forever. Stopping the transfer brings up a small window telling
me that the the download failed due to network problems.

Importing the CRLs works if you download them manually using the context menu
and then drag'n'drop the files into the browser window. However in this case the
automatic update feature doesn't work since the URL points to the files on the
local harddisk.

TrustCenter notes on the mentioned page that "Netscape only supports CRLs of
version 1". No idea if this is the reason or not. Makes me wonder however why
it's then possible to import the CRLs manually.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

->Whoops, this one's been sitting here a while. Over to PSM.

Comment 2

[Stephane Saux]

I suspect that the server is not giving the right mime type to the browser.
This functionality works with, for example:
http://crl.verisign.com/RSASecureServer.crl

Mozilla will figure it out if the extension of the file ends in .crl, or the
proper mime type is passed by the cgi.

Comment 3

[Tony Capel]

Attachment: Transcript of HTTP sessions showning varying content types returned, one of which demonstrates Mozilla not overriding content type (and not processing valid crl)

Comment 4

[Kai Engert (:KaiE:)]

What Stephane said.

application/octect-stream is a general content type for untyped binary data.

The processing will only work if the cgi script returns a correct content type
like application/x-pkcs7-crl

Regarding your other question, automated updating, you can still enable
automatic update if you go to edit/prefs/privacy/validation/manage crls and edit
your crl.


Resolving bug as invalid.

Comment 5

[Tony Capel]

Kai: 
I understood from Stephane's comment that either the mime type OR the extension
would allow Mozilla "to figure it out".  If this is design behaviour this is
fine; but a note somewhere would be helpful since at least in my case I was
mystified by the behaviour (i.e. reading the file using HTTP failed, by FTP or
directly from a disk file the same crl file was ok).  And programs like MS IE
don't seem to operate the same way.

On your second point, "edit/prefs/privacy/validation/manage crls and edit
your crl".  As far as I can tell you cannot edit the url.  You can only
enable/disable updating and set update time/frequency. Additionally of course,
you cannot enter a new url either (only delete them).  So you cannot download
the file, read it directly from a disk to get Moz to recognize it as a crl, then
edit the url to point back to the original location (and presumably when
accessed this way the content-type has no bearing?).  Actually the easiest work
around is to use FTP, that seems to work.

I have verified that this is still the case in 1.4RC2.

Comment 6

[Kai Engert (:KaiE:)]

> either the mime type OR the extension
> would allow Mozilla "to figure it out"

I think the extension is not used by Mozilla, we rely completely on the mime
type returned by the server.