-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Steve,
On 6/13/13 5:27 PM, Steve Nickels wrote: >>> I figured out the problem. The error was due to my system >>> rebasing the libeay32.dll library from its desired base address >>> of 0xFB00000. According to OpenSSL documents, this is supposed >>> to generate a specific error message of >>> FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED, but >> because I wasn't >>> seeing that, I didn't think that was the problem. >> >> Interesting. Do you think it was being swallowed-up somewhere? >> Like I said, tcnative/FIPS hasn't gotten a huge amount of >> exposure. > > I think the error message issue might be a problem with OpenSSL > itself. As far as I can tell, tcnative is simply parroting back > the error message that OpenSSL gives it. It is, but the function we are using says it gets the "first" error from the error queue. I suppose we could drain the entire error queue looking for all messages and concatenate them together or something. We aren't inspecting the entire error queue. >> Do you think there are ways it could be improved? Better error >> checking, etc.? I implemented it as simply as I possibly could. > > The biggest problem seems to be that something in Tomcat on Windows > is interfering with OpenSSL's normal base address request > (0xFB00000). Normally this doesn't matter, but with the FIPS > build, if the base address of the library is moved from what it > expects, the result is a fingerprint error when FIPS mode is > enabled. This could be a problem on *NIX as well -- any library may be re-located by the loader for any reason. > I ran the openssl utility on the same system as Tomcat, and > Process Explorer shows that its copy of libeay32.dll stays at the > correct address. Additionally, I tested the FIPS-compatible > libeay32.dll on a different server with Tomcat, and had the same > problem. This seems to indicate that the memory address issue is > specific to Tomcat, not the server. Or running within a JVM which has a significant amount of native code that gets loaded first, which may cause the loader to re-locate the library when it finally gets loaded. Any interest in trying some Java-based testing using libtcnative? > I can't tell from Process Explorer why libeay32.dll is being > rebased (I didn't see any other libraries under tomcat7.exe that > were obviously taking up the same address space). I think it's > going to take someone with more experience with both Windows and > Tomcat than I to figure that one out. I suppose it might be worthy > of a bug report, at least. That would be good -- bug reports have more visibility than mailing list posts, and it's a good place to collect information all in one place. I'm curious: what base address did you use when you changed it? > If the fix for the memory rebasing issue ends up being that > OpenSSL needs to be configured with a different base address, that > would be good to include in the build documentation for tcnative. > The file \jni\native\srclib\BUILDING would be a good place for such > a note. But, if the interfering Tomcat piece were to be found and > resolved, you wouldn't need it. I suspect this is an OS-related thing that Tomcat can't really affect. Note that (other than tcnative and the win32 service-launcher), Tomcat doesn't have any native code at all, so it can't really affect this kind of stuff. Tomcat just issues a System.loadLibrary() call and lets the JVM and OS take over. >>> With my test application, the original base address was not >>> being changed by the OS, according to process explorer, which >>> is why it worked with the original build. >>> >>> Thanks for your help! >> >> No problem. If there were any other gotchas you found when >> building tcnative/FIPS/win32 could you let us know? Actually, >> creating a Wiki page is easy to do and you could help others who >> are trying to do the same thing. > > One minor issue I found when building tcnative on Windows was that > the BUILDING file in the \jni\native directory in > tomcat-native-1.1.27-win32-src.zip appears to contain UNIX build > instructions. This probably isn't appropriate, since the zip file > is specific to win32. That's a good point. Could you log that in Bugzilla as well? There are (brief) building instructions on http://tomcat.apache.org/native-doc/ but they should probably also be in the BUILDING file. > If there's a good place to put a wiki page about this, let me > know, and I can try to add something. Really anywhere under http://wiki.apache.org/tomcat/FAQ would be great. If I were looking for information about this, I'm not sure where I'd look first. Perhaps under "Security"? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRuj2oAAoJEBzwKT+lPKRY2rYQAKbgmjzUDFF3FeoJRZ72yhFf ibtmO/7E5KFk9OOIVoDrFrIslCmfquHTeQZQHD2UrJ00OOL9tgSqbd5pyapfXjK9 LjV7BgyWu0YhiVbjDhXYpZQgzYPsUUHb1KyNhzVjqhwOJYaqhnnw6Bx5M1jc6FJb oA0WZC8ODxgMpqnBG7qrB/mDIcRr9UViv/k7ChDn4mZeHmVfTNsB9NUkNWXCXZlc HOzxA9imc7EcManaesIMqHbwTwbggR+nnsvxGn2k3aNmS1Wp5W+Svjjco1E7xK8b T44AGEyGAmywFvOF24Cm89rfMkCouat2fAdOH29myEtbHm0B27umjXaddifEvjE9 Rxf2oyW5Nb/N2ZQwBgdFMHXKdtMVGiKinqJhqVlLVr1NBarfaU8m85Kfv7tq+eIu tVezTMDzRyM3tMkhYDxRzNQ1/vlgbIFcapR+uiJSbQJVnnOl6IStYznhWja4f7t7 WF7xjPTGGlRgFy7MUwI97U/bnCD8S5PnJIjENuanoa1ebTkRfDGRgZNx6/v0Cm8H kpATMBRNEeznxdLVpC4hONjOLa/6AVvvmiA+kvfuKnDomcEKdU/ZAx88EoZt7HQv HeFWDNp8sJIB8wXq/Srn48kgfAuPOVpwHBIlS8nnNGUwjasxZtvyOkMn5oS7klEF 11YGFTZAd8SAuf8Xy8bl =SPZh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
