Re: Tomcat, SSL, IE, and .pdf downloads
Mark Leone midnightjava at cox.net writes: BTW, switching gears, I should have mentioned the following in my previous email. I suspect that the IE workaround you described will only work for SSL connections. Tomcat (and presumably any other good HTTP server) will set the cache control headers to prevent caching of any response generated from a protected context (i.e. one in which there is a security-constraint element), whether the connection is made with HTTPS (i.e., SSL) or HTTP. The IE option you described seems to apply only to encrypted data, so it probably won't help IE users who are trying to download files from a protected context via HTTP. Correction to my previous post: The work-around apparently is not needed for non-SSL connections. I did a little experiment and found that IE doesn't have a problem with non-SSL responses that include headers with the no-cache cache directive. This alleviates the security concern I raised, since Tomcat can be configured to prohibit caching from protected contexts for non-SSL connections, and this behavior only needs to be overriden for SSL connections to satisfy IE, which I guess is not as problematic from a security standpoint. It's still a compatibility issue, IMO, since implementers will regularly encounter the problem with SSL connections and wonder what is going on. Also, Mary Beth, I was unable to duplicate your results with unchecking the don't allow encrypted data to be cached to disk option. I commented out the valve in server.xml so that IE was not working properly for SSL file downloads. Then I unchecked the aforementioned option in IE, and it did not fix the problem. I'm wondering if you're dealing with a different issue. I'd like to know if you apply the valve fix in server.xml, and if it solves your problem. Did you do anything else to make IE work without the valve in server.xml? -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat, SSL, IE, and .pdf downloads
I think that I'll be leaving the moral decisions to my network admins. They can decide what they feel is the right answer with regard to network security. But it's good to know that there is a way to fix the problem. Thanks again to everyone for all the input! -Mary Beth -Original Message- From: Mark Leone [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 9:24 PM To: Tomcat Users List Subject: Re: Tomcat, SSL, IE, and .pdf downloads Mary-Beth, be advised that applying the fix in Tomcat is arguably the moral equivalent of what you said you didn't want to do (i.e., uncheck don't allow encrypted data to be cached to disk in IE). By inserting the valve that ensures that the cache-control headers are not set, you're not only permitting IE to cache the response, but you're also permitting any HTTP intermediaries to do so. I wouldn't be concerned about the former (since the user can control the browser cache), but the latter can be an issue if you have HTTP intermediaries in the path and you don't want any copies of the response hanging around. It would actually be more secure to just uncheck the setting in IE (since you indicated that works), and retain the no-cache behavior for the HTTP intermediaries; but that's probably unworkable from an interop standpoint. All IE users would have to configure their browser properly, or they will be told that your site is unavailable. The unfortunate reality is that because one particular user agent (IE) is applying more restrictive caching behavior than is warranted by the spec, the server has to relax the caching behavior where it really needs to be restricted in many cases, if IE compatibility with default settings is to be maintained. There's an important lesson here, but I don't think the party that needs to learn it is listening. -Mark Mark Thomas wrote: This seems to be a popular subject today. Try looking at http://marc.theaimsgroup.com/?l=tomcat-userm=111811136603781w=2 Mark Panichi, Mary-Beth wrote: Greetings ~ We're having issues downloading .pdf files in SSL. I've been all over the web trying to find solutions. The issue appears to be interaction between Tomcat and InternetExplorer. IE appears to be corrupting the pdf files. There's an IE patch out there, but we've patched past that. The fix that they list, to uncheck the don't allow encrypted data to be cached to disk, works, but it's a setting that for security reasons we don't want to leave unchecked. I've tried all manner of setting headers for cache-control, etc.. We're dynamically generating the .pdf files, and streaming them to the jsp page. I've tried also saving the pdf's physically to the server and then getting them, but that didn't work either. Has anyone run into this issue? Does anyone have a solution? I've seen lots of suggestions out there, but nothing that actually works. Thanks! Mary Beth Panichi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat, SSL, IE, and .pdf downloads
Another newbie question -- how do I tell which authenticator we're using? Does tomcat use a default one? I was looking at the API, but there isn't enough explanation there. And I didn't see anything in the Tomcat doco. Thanks, -Mary Beth -Original Message- From: Mark Leone [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 9:24 PM To: Tomcat Users List Subject: Re: Tomcat, SSL, IE, and .pdf downloads Mary-Beth, be advised that applying the fix in Tomcat is arguably the moral equivalent of what you said you didn't want to do (i.e., uncheck don't allow encrypted data to be cached to disk in IE). By inserting the valve that ensures that the cache-control headers are not set, you're not only permitting IE to cache the response, but you're also permitting any HTTP intermediaries to do so. I wouldn't be concerned about the former (since the user can control the browser cache), but the latter can be an issue if you have HTTP intermediaries in the path and you don't want any copies of the response hanging around. It would actually be more secure to just uncheck the setting in IE (since you indicated that works), and retain the no-cache behavior for the HTTP intermediaries; but that's probably unworkable from an interop standpoint. All IE users would have to configure their browser properly, or they will be told that your site is unavailable. The unfortunate reality is that because one particular user agent (IE) is applying more restrictive caching behavior than is warranted by the spec, the server has to relax the caching behavior where it really needs to be restricted in many cases, if IE compatibility with default settings is to be maintained. There's an important lesson here, but I don't think the party that needs to learn it is listening. -Mark Mark Thomas wrote: This seems to be a popular subject today. Try looking at http://marc.theaimsgroup.com/?l=tomcat-userm=111811136603781w=2 Mark Panichi, Mary-Beth wrote: Greetings ~ We're having issues downloading .pdf files in SSL. I've been all over the web trying to find solutions. The issue appears to be interaction between Tomcat and InternetExplorer. IE appears to be corrupting the pdf files. There's an IE patch out there, but we've patched past that. The fix that they list, to uncheck the don't allow encrypted data to be cached to disk, works, but it's a setting that for security reasons we don't want to leave unchecked. I've tried all manner of setting headers for cache-control, etc.. We're dynamically generating the .pdf files, and streaming them to the jsp page. I've tried also saving the pdf's physically to the server and then getting them, but that didn't work either. Has anyone run into this issue? Does anyone have a solution? I've seen lots of suggestions out there, but nothing that actually works. Thanks! Mary Beth Panichi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat, SSL, IE, and .pdf downloads
You may have the following element in your web app's web.xml: login-config auth-methodsome_authentication_method/auth-method realm-namesome_realm_name/realm-name /login-config (If you don't, then you're probably not serving the content from a protected context, and this issue doesn't apply to you.) Possible values for some_authentication_method are BASIC, DIGEST, and FORM. BASIC authentication means the user agent (e.g. the browser) will send a cleartext username and password, which of course can be easily intercepted and therefore compromised. DIGEST authentication means the user agent will send a one way hash value that was created with the username, password, and some random data as inputs. The server has the same hash value stored, so it can determine that the user has properly authenticated; but since it's a one-way hash, an eavesdropper cannot work backwards and figure out the password. And because of the random data, coordinated between the client and server, no one can record and replay the hash value to spoof the authentication. It's fairly secure, but not as good as SSL or TLS. FORM authentication means the user enters authenticating information via an HTML form, which is encoded according to the content type specified in the enctype attribute of the HTML FORM element. You need to set the classname attribute of the valve element in server.xml appropriately, as described in the email referenced below. The attribute value must match the authentication method chosen from the above list. The three authenticator classes are located in package org.apache.catalina.authenticator, and the classnames are BasicAuthenticator, DigestAuthenticator, and FormAuthenticator.* *So, for example, if you're using DIGEST authentication, your valve element would look like this.* * Valve className=org.apache.catalina.authenticator.DigestAuthenticator disableProxyCaching=false / BTW, switching gears, I should have mentioned the following in my previous email. I suspect that the IE workaround you described will only work for SSL connections. Tomcat (and presumably any other good HTTP server) will set the cache control headers to prevent caching of any response generated from a protected context (i.e. one in which there is a security-constraint element), whether the connection is made with HTTPS (i.e., SSL) or HTTP. The IE option you described seems to apply only to encrypted data, so it probably won't help IE users who are trying to download files from a protected context via HTTP. This is a further irony, since cached SSL data is not as problematic. It's the plaintext data you want to purge, and that's precisely the data for which you have to permit caching because of the way IE is implemented. (However, it's possible that the IE check option is poorly worded. Perhaps it actually applies to any response for which the cache control headers are set to no-cache.) -Mark Panichi, Mary-Beth wrote: Another newbie question -- how do I tell which authenticator we're using? Does tomcat use a default one? I was looking at the API, but there isn't enough explanation there. And I didn't see anything in the Tomcat doco. Thanks, -Mary Beth -Original Message- From: Mark Leone [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 9:24 PM To: Tomcat Users List Subject: Re: Tomcat, SSL, IE, and .pdf downloads Mary-Beth, be advised that applying the fix in Tomcat is arguably the moral equivalent of what you said you didn't want to do (i.e., uncheck don't allow encrypted data to be cached to disk in IE). By inserting the valve that ensures that the cache-control headers are not set, you're not only permitting IE to cache the response, but you're also permitting any HTTP intermediaries to do so. I wouldn't be concerned about the former (since the user can control the browser cache), but the latter can be an issue if you have HTTP intermediaries in the path and you don't want any copies of the response hanging around. It would actually be more secure to just uncheck the setting in IE (since you indicated that works), and retain the no-cache behavior for the HTTP intermediaries; but that's probably unworkable from an interop standpoint. All IE users would have to configure their browser properly, or they will be told that your site is unavailable. The unfortunate reality is that because one particular user agent (IE) is applying more restrictive caching behavior than is warranted by the spec, the server has to relax the caching behavior where it really needs to be restricted in many cases, if IE compatibility with default settings is to be maintained. There's an important lesson here, but I don't think the party that needs to learn it is listening. -Mark Mark Thomas wrote: This seems to be a popular subject today. Try looking at http://marc.theaimsgroup.com/?l=tomcat-userm=111811136603781w=2 Mark Panichi, Mary-Beth wrote
Re: Tomcat, SSL, IE, and .pdf downloads
This seems to be a popular subject today. Try looking at http://marc.theaimsgroup.com/?l=tomcat-userm=111811136603781w=2 Mark Panichi, Mary-Beth wrote: Greetings ~ We're having issues downloading .pdf files in SSL. I've been all over the web trying to find solutions. The issue appears to be interaction between Tomcat and InternetExplorer. IE appears to be corrupting the pdf files. There's an IE patch out there, but we've patched past that. The fix that they list, to uncheck the don't allow encrypted data to be cached to disk, works, but it's a setting that for security reasons we don't want to leave unchecked. I've tried all manner of setting headers for cache-control, etc.. We're dynamically generating the .pdf files, and streaming them to the jsp page. I've tried also saving the pdf's physically to the server and then getting them, but that didn't work either. Has anyone run into this issue? Does anyone have a solution? I've seen lots of suggestions out there, but nothing that actually works. Thanks! Mary Beth Panichi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat, SSL, IE, and .pdf downloads
Ironically, I ran into this last week as well. However, I was running my app on Websphere, and the cause (and solution) was subtly different... It is a Struts-based application. I had the nocache RequestProcessor setting in effect. This caused PDF generation to fail under SSL, same as the referenced issue. Removing the setting resolved the issue, but I then had to create a quick filter that would set the same cache headers the nocache setting does but allows me to define a list of paths that they should NOT be set for. So, now everything in the app gets the cache headers set EXCEPT the three paths accessed to generate PDFs, and life is good again. The point is be sure that it's no Tomcat setting the headers... and even if it is and you turn that off, be sure they aren't getting set anywhere else, like Struts, or some other app code. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, June 7, 2005 2:46 pm, Mark Thomas said: This seems to be a popular subject today. Try looking at http://marc.theaimsgroup.com/?l=tomcat-userm=111811136603781w=2 Mark Panichi, Mary-Beth wrote: Greetings ~ We're having issues downloading .pdf files in SSL. I've been all over the web trying to find solutions. The issue appears to be interaction between Tomcat and InternetExplorer. IE appears to be corrupting the pdf files. There's an IE patch out there, but we've patched past that. The fix that they list, to uncheck the don't allow encrypted data to be cached to disk, works, but it's a setting that for security reasons we don't want to leave unchecked. I've tried all manner of setting headers for cache-control, etc.. We're dynamically generating the .pdf files, and streaming them to the jsp page. I've tried also saving the pdf's physically to the server and then getting them, but that didn't work either. Has anyone run into this issue? Does anyone have a solution? I've seen lots of suggestions out there, but nothing that actually works. Thanks! Mary Beth Panichi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat, SSL, IE, and .pdf downloads
Mary-Beth, be advised that applying the fix in Tomcat is arguably the moral equivalent of what you said you didn't want to do (i.e., uncheck don't allow encrypted data to be cached to disk in IE). By inserting the valve that ensures that the cache-control headers are not set, you're not only permitting IE to cache the response, but you're also permitting any HTTP intermediaries to do so. I wouldn't be concerned about the former (since the user can control the browser cache), but the latter can be an issue if you have HTTP intermediaries in the path and you don't want any copies of the response hanging around. It would actually be more secure to just uncheck the setting in IE (since you indicated that works), and retain the no-cache behavior for the HTTP intermediaries; but that's probably unworkable from an interop standpoint. All IE users would have to configure their browser properly, or they will be told that your site is unavailable. The unfortunate reality is that because one particular user agent (IE) is applying more restrictive caching behavior than is warranted by the spec, the server has to relax the caching behavior where it really needs to be restricted in many cases, if IE compatibility with default settings is to be maintained. There's an important lesson here, but I don't think the party that needs to learn it is listening. -Mark Mark Thomas wrote: This seems to be a popular subject today. Try looking at http://marc.theaimsgroup.com/?l=tomcat-userm=111811136603781w=2 Mark Panichi, Mary-Beth wrote: Greetings ~ We're having issues downloading .pdf files in SSL. I've been all over the web trying to find solutions. The issue appears to be interaction between Tomcat and InternetExplorer. IE appears to be corrupting the pdf files. There's an IE patch out there, but we've patched past that. The fix that they list, to uncheck the don't allow encrypted data to be cached to disk, works, but it's a setting that for security reasons we don't want to leave unchecked. I've tried all manner of setting headers for cache-control, etc.. We're dynamically generating the .pdf files, and streaming them to the jsp page. I've tried also saving the pdf's physically to the server and then getting them, but that didn't work either. Has anyone run into this issue? Does anyone have a solution? I've seen lots of suggestions out there, but nothing that actually works. Thanks! Mary Beth Panichi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
