Since Firefox doesn't allow connections over port 143 (IMAP), it should also disallow connections over port 993 (IMAP over SSL). I imagine that any exploits where http traffic is treated as IMAP traffic also work when https traffic is treated as IMAP-over-SSL traffic. Steps to reproduce: 1. Load https://turing.cs.hmc.edu:993/ Result: * OK Courier-IMAP ready. Copyright 1998-2003 Double Precision, Inc. See COPYING for distribution information. GET NO Error in IMAP command received by server. Host: NO Error in IMAP command received by server. User-Agent: NO Error in IMAP command received by server. Accept: NO Error in IMAP command received by server. Accept-Language: NO Error in IMAP command received by server. Accept-Encoding: NO Error in IMAP command received by server. Accept-Charset: NO Error in IMAP command received by server. Keep-Alive: NO Error in IMAP command received by server. Connection: NO Error in IMAP command received by server. * BYE [ALERT] Fatal error: TOO MANY CONSECUTIVE PROTOCOL VIOLATIONS: The server seems to treat each line of the http request header as a command. With POST and a slightly more lenient server (or a proxy that reduces the number of headers), an attacker might be able to get a user's browser to send arbitrary IMAP commands to an IMAP server.

http://support.microsoft.com/default.aspx?scid=kb;en-us;278339 lists the SSL ports used by the Microsoft Exchange mail server. Anyone know the hostname of an Exchange server I can poke at?

https://turing.cs.hmc.edu:995/ (POP over SSL) +OK Qpopper (version 4.0.3) at turing starting. <24580.1122062855@turing> -ERR Unknown command: "get". -ERR Unknown command: "host:". -ERR Too many arguments supplied. -ERR Unknown command: "accept:". -ERR Unknown command: "accept-language:". -ERR Unknown command: "accept-encoding:". -ERR Unknown command: "accept-charset:". -ERR Unknown command: "keep-alive:". -ERR Unknown command: "connection:". -ERR POP timeout from turing +OK Pop server at turing signing off.

Dan, can you take care of this, either plus or minus and help it get assigned if we plus it?

Dan, please plus if you think we have to have this for 1.5. Thanks.

Comment on attachment 225872 [details] [diff] [review] add standard SSL mail ports I see no problem with this. Don't you also have to change the AllowPort() function in for those schemes that want to use these ports?

Forgot the ldap ssl port. carrying over darin's SR: non-substantive change and he'll get a chance to object with the 1.8.1 approval request. To answer Doug's question, the mail protcols simply allow every port and LDAP already checks for the normal and SSL ports listed here. No AllowPort() changes are necessary.

Comment on attachment 225963 [details] [diff] [review] as above plus ldap SSL a=darin on behalf of drivers (please land this on the MOZILLA_1_8_BRANCH promptly and add the fixed1.8.1 keyword to the bug)

Please land this ASAP so that it does not hold up the FF2 beta1 release. Or, if we should ship FF2 beta1 without this fix then please let us know.

Fix checked in to trunk and 1.8 branch

Great. You just broke the ability for any FireFox user to LOOK AT the certificates from his IMAPS or POPS server using his browser. https://lunarpages.com:993/ doesn't work any more. Users will no longer be able to use this simple technique to see what's wrong with their email server certificates. Sure seems like changes like this ought to be discussed in mozilla security mailing list first.

ff2b2 windows/linux localhost:993 -> This address is restricted

In case people have written web apps (internal?) that use these ports we don't want that kind of breakage to prevent people from taking a security fix. This low-impact problem shouldn't get fixed in 1.8.0.x