Menu
▾
▴
fetchmail-devel
|
From: Daniel R. G. <sk...@iS...> - 2006-04-23 09:30:24
|
I'm using fetchmail to download mail via SSL-secured POP3 from mail.mydomain.com, a server maintained by webhost.com. This server is not dedicated to my domain; it is an alias for one of a handful of mega-mail servers run by webhost.com. The SSL certificate on mail.mydomain.com (and all the other mail servers) is actually for mail.webhost.com. I can't connect to mail.webhost.com, however, because it is not the same mega-server as the one for my domain; it doesn't recognize my username/password. (I fully concede that webhost.com, to put it mildly, could manage their SSL services better. They've been following this practice for a long time, unfortunately, and it's quite unlikely that they'll go to the trouble of changing it.) It would be very helpful to be able to say, "connect to server A, but for the purposes of SSL, pretend it's called B." Right now, there is no way to specify this. I think that there wouldn't even be a need to introduce a new keyword; this semantic could reasonably be stuffed into "aka". So that, for the above-described scenario, I could say poll mail.mydomain.com aka mail.webhost.com protocol pop3 username ... password ... ssl fetchall and have everything work dandily. I'm not sure about how the implementation would go, however. The CommonName matching takes place in SSL_verify_callback(), which takes an X509_STORE_CTX and two ints as parameters. The arguments for "aka", however, go into a (struct query)->(struct hostdata)->akalist field, and there doesn't seem to be a way to get to that from the callback. Would appreciate any thoughts/insight on this.... --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Matthias A. <mat...@gm...> - 2006-04-23 22:15:45
|
"Daniel Richard G." <sk...@iS...> writes: > I think that there wouldn't even be a need to introduce a new keyword; > this semantic could reasonably be stuffed into "aka". So that, for the > above-described scenario, I could say > > poll mail.mydomain.com aka mail.webhost.com protocol pop3 > username ... password ... ssl fetchall > > and have everything work dandily. Well, fetchmail is in fact talking to mail.mydomain.com, so allowing certificates for other domains on the server wouldn't be the right thing to do. You can however obtain the server's certificate fingerprint (run fetchmail with -v (in verbose mode)) and then use the sslfingerprint option to suppress the warning. Fetchmail will then abort the connection if the fingerprint does not match. -- Matthias Andree |
|
From: Daniel R. G. <sk...@iS...> - 2006-04-23 23:11:26
|
On Sun, 2006 Apr 23 22:16:07 +0200, Matthias Andree wrote: > > Well, fetchmail is in fact talking to mail.mydomain.com, so allowing > certificates for other domains on the server wouldn't be the right thing > to do. There is no way for mail.mydomain.com to have an SSL certificate with CN=mail.mydomain.com. Not unless I shell out for a dedicated IP address. Alternate names are not a solution either, unless one wants to download a certificate with 100000+ alternates :] I agree that webhost.com did a lousy job of setting up their SSL mail services, but given that that's the current, unlikely-to-change-in-the- near-future reality, the issue becomes fetchmail's flexibility in handling a less-than-ideal server situation. > You can however obtain the server's certificate fingerprint (run > fetchmail with -v (in verbose mode)) and then use the sslfingerprint > option to suppress the warning. Fetchmail will then abort the connection > if the fingerprint does not match. That's what I'm doing for now, but I still get the "CommonName mismatch" warnings. (Twice for every connection, in fact.) I want to get rid of those, and I'd still like to be able to do full certificate checking (modulo the specifically-configured exception for the CN). --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Matthias A. <mat...@gm...> - 2006-04-24 14:49:01
|
"Daniel Richard G." <sk...@iS...> writes: > On Sun, 2006 Apr 23 22:16:07 +0200, Matthias Andree wrote: >> >> Well, fetchmail is in fact talking to mail.mydomain.com, so allowing >> certificates for other domains on the server wouldn't be the right thing >> to do. > > There is no way for mail.mydomain.com to have an SSL certificate with > CN=mail.mydomain.com. Not unless I shell out for a dedicated IP address. > Alternate names are not a solution either, unless one wants to download a > certificate with 100000+ alternates :] Well... > I agree that webhost.com did a lousy job of setting up their SSL mail > services, but given that that's the current, unlikely-to-change-in-the- > near-future reality, the issue becomes fetchmail's flexibility in handling > a less-than-ideal server situation. I'll ponder this a bit, and see if "aka" or "via" should be overloaded or a new option be introduced. I usually prefer separate options because sooner or later someone will find a use case where overloading a token restricts flexibility again and the initial enthusiasum for saving yet another token turns into frustration because existing documentation, practice and configuration locks the software in to its former way of overloading the token for quite a while. Currently the expected name is the "via" name if given, otherwise the poll name. >> You can however obtain the server's certificate fingerprint (run >> fetchmail with -v (in verbose mode)) and then use the sslfingerprint >> option to suppress the warning. Fetchmail will then abort the connection >> if the fingerprint does not match. > > That's what I'm doing for now, but I still get the "CommonName mismatch" > warnings. (Twice for every connection, in fact.) I want to get rid of > those, and I'd still like to be able to do full certificate checking > (modulo the specifically-configured exception for the CN). Which indicates that you are running a version before 6.3.4. This version fixed this particular issue (well, as long as "sslcertck" isn't enabled, which would deliberately turn the CN mismatch into a fatal socket errors anyways). -- Matthias Andree |
|
From: Daniel R. G. <sk...@iS...> - 2006-04-25 06:50:14
|
On Mon, 2006 Apr 24 14:49:19 +0200, Matthias Andree wrote: > > I'll ponder this a bit, and see if "aka" or "via" should be overloaded > or a new option be introduced. I usually prefer separate options because > sooner or later someone will find a use case where overloading a token > restricts flexibility again and the initial enthusiasum for saving yet > another token turns into frustration because existing documentation, > practice and configuration locks the software in to its former way of > overloading the token for quite a while. That sounds suspiciously like wisdom :-) Maybe something like "sslalternate" (or "sslalt"), given that this would essentially simulate an alternate-name on the server certificate. This could more reasonably become a new field in X509_STORE_CTX, which makes the integration cleaner. (I can try my hand at a patch, if you like... any pointers/caveats I should know?) > Currently the expected name is the "via" name if given, otherwise the > poll name. And the proposed new feature/keyword would basically be the reverse of that. Hmm. > > That's what I'm doing for now, but I still get the "CommonName mismatch" > > warnings. (Twice for every connection, in fact.) I want to get rid of > > Which indicates that you are running a version before 6.3.4. This > version fixed this particular issue (well, as long as "sslcertck" isn't > enabled, which would deliberately turn the CN mismatch into a fatal > socket errors anyways). Yes indeed... 6.2.5, as shipped with Debian sarge :> *download* *download* *build* *build* Okay, I have 6.3.4 now. Strike that second warning.... --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Daniel R. G. <sk...@iS...> - 2006-05-01 16:39:59
Attachments:
sslcommonname.patch
|
I've gone ahead and put together a preliminary patch, against the SVN code. This implements a new keyword: "sslcommonname". (Forget my earlier suggestion of "sslalternate"---I wasn't thinking straight when I made it :] The approach I took was basically to find all instances of "sslfingerprint", and implement the new keyword similarly at each turn (which turned out to be quite easy). On the downside, you can only specify one CommonName, whereas I had originally envisioned allowing many. You'll notice that the critical bits are in driver.c, imap.c and pop3.c, before and when the call to SSLOpen() is made. Everything else is supporting boilerplate. Please let me know how this patch looks, and if it looks good, I'll flesh it out (with deltas on the man page and documentation) for submission. --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Matthias A. <mat...@gm...> - 2006-05-02 00:52:10
|
"Daniel Richard G." <sk...@iS...> writes: > I've gone ahead and put together a preliminary patch, against the SVN code. > This implements a new keyword: "sslcommonname". (Forget my earlier > suggestion of "sslalternate"---I wasn't thinking straight when I made it :] > > The approach I took was basically to find all instances of > "sslfingerprint", and implement the new keyword similarly at each turn > (which turned out to be quite easy). On the downside, you can only specify > one CommonName, whereas I had originally envisioned allowing many. Well, there are string list functions inside fetchmail, and these can help with the implementation. I wonder if that's useful though - that would mean servers behind a load balancer use different common names. > You'll notice that the critical bits are in driver.c, imap.c and pop3.c, > before and when the call to SSLOpen() is made. Everything else is > supporting boilerplate. > > Please let me know how this patch looks, and if it looks good, I'll flesh > it out (with deltas on the man page and documentation) for submission. Looks good to me (I haven't applied and tested it though yet). A tiny bit, the "cname" variables might better be renamed (perhaps to "comname" or sslcommonname) to avoid someone (like myself) from assuming it might have to do with the DNS CNAME resource record (canonical name). Thanks for your work! -- Matthias Andree |
|
From: Daniel R. G. <sk...@iS...> - 2006-05-02 05:14:57
|
On Tue, 2006 May 02 00:52:29 +0200, Matthias Andree wrote: > > Well, there are string list functions inside fetchmail, and these can > help with the implementation. I wonder if that's useful though - that > would mean servers behind a load balancer use different common names. I was thinking of a single DNS name resolving to multiple such hosts, but yes, same idea. A really, really badly broken SSL setup }:) Looking at the code, however, I think I'll probably shy away from that. SSL_verify_callback() already has too many levels of indentation, and checking against multiple common names would require another one (for a nested loop). Someone really should refactor that function.... > Looks good to me (I haven't applied and tested it though yet). > > A tiny bit, the "cname" variables might better be renamed (perhaps to > "comname" or sslcommonname) to avoid someone (like myself) from assuming > it might have to do with the DNS CNAME resource record (canonical name). Excellent point. Will do that. > Thanks for your work! Glad to contribute. I'll flesh out the patch, tweak it as advised, and submit it when ready. Sincerely yours, --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X