RE: Better SSL connector setup
Enough already guys please. EJP -Original Message- From: users-digest-h...@tomcat.apache.org [mailto:users-digest-h...@tomcat.apache.org] Sent: Thursday, 11 April 2013 11:48 PM To: users@tomcat.apache.org Subject: users Digest 11 Apr 2013 13:48:25 - Issue 11342 users Digest 11 Apr 2013 13:48:25 - Issue 11342 Topics (messages 241110 through 241119) Re: Better SSL connector setup 241110 by: Mark Eggers Re: Resource management in new Tomcat JDBC connection pool. 24 by: Igor Urisman Re: Tomcat access log reveals hack attempt: HEAD /manager/html HTTP/1.0 404 241112 by: Esmond Pitt 241113 by: Howard W. Smith, Jr. 241114 by: Howard W. Smith, Jr. 241119 by: Jeffrey Janner RE : Tomcat 6.0.35 Crashed again 241115 by: saumil shah Re: Inno Setup Script? 241116 by: James Green 241117 by: Konstantin Kolinko 241118 by: James Green Administrivia: - To post to the list, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-digest-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-digest-h...@tomcat.apache.org -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Better SSL connector setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/9/13 11:54 AM, André Warnier wrote: Harris, Jeffrey E. wrote: Chris, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 09, 2013 10:01 AM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/13 8:17 AM, Harris, Jeffrey E. wrote: -Original Message- From: André Warnier [mailto:aw@ice- sa.com] Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users List Subject: Re: Better SSL connector setup Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You can improve the performance of the existing RS-232 modem pool by doing some ROT-13 and Fourier transforms prior to data encoding. However, this does require the equivalent capability on the receiving side. - -1 Using ROT-13 can certainly improve the security of your data in-transit and *is* a NIST recommendation, but it unfortunately does not improve performance as it introduces an additional operation in the pipeline. As usual, real security is a trade-off between convenience (here, speed) and actual security (the superior cipher algorithm ROT-13). I believe recent versions of OpenSSL (0.9.1c?) include the new ROT13-XOR- MD2 cipher, but since it is optimized for 8-bit processors you need to make sure to have a modern CPU -- I recommend one of the DX2 Intel processors. Okay, it does not improve performance, but it sure confuses the heck out of man-in-the-middle attacks! As for Fourier transforms, that's just security through obscurity (though it's pretty good obscurity). Fast Fourier transforms also work best with data sizes that are powers-of-two in length and so your throughput can experience odd pulsing behavior while your buffers fill waiting to be transformed. Unless you have one of the aforementioned DX2 style processors coupled with a V.22bis-capable device, you are probably not going to be able to keep up with all the traffic your Gopher server is likely to generate. Well, I was focusing on performance here, not security. And if I use my Amiga 1000, I can invoke hardware security because of the non-standard RS-232 port (just try and connect a regular RS-232 cable to that system, and see how quickly the modem shorts out!), and because the instruction set uses Motorola 68000 instructions, not DX2 Intel instructions. That's not really security either. Any common optical RS-232 isolator (like the one shown here : http://www.commfront.com/rs232-rs485-rs422-serial-converters/RS232-Isolator-7-wire.htm) will easily overcome that issue. I started using these everywhere after I blew up the line drivers of my Soroc terminal a couple of times by forgetting to switch it off before I unplugged it. I don't know what the optical nature of the isolator does to the security by obscurity aspect though, I suspect that it may make a man-in-the-middle attack easier (as long as the man is not really in the middle physically of course). For SSL however, due to the higher bitrate, I would recommend a conversion to RS485 (with this e.g. : http://www.szatc.com/english/showpro.asp?articleid=169) (beware of embedded Trojans though). USB is just a fad. Stick with SCSI unless you want to have a whole lot of useless hardware in 18 months. Also, for your Amiga, you may want to consider swapping the 68000 processor by a 68010. It is pin-compatible and provides a significant speed boost, maybe enough to allow you to switch from a 48-bit encryption scheme to a 128-bit scheme. Don't forget to install the Microsoft High Encryption pack, or your browsers won't be able to decrypt that stuff. I think you have to register with the DOD in order to deploy ciphers of that strength. - -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/ iQIcBAEBCAAGBQJRZY6gAAoJEBzwKT+lPKRYRlEP/1ejlObFxUBurd1olB/iPPOm YjkaIltCTAlRop9NsaLGJwU4Mgn5gUHVXD+3j/UpnfVt8i6EIVkKcAjQRAlaWE/Y G6GXfueW8Pc1Rm8geOMuwtQkvAE5p3rpryP7xWdEps3fFdMgK8VFlsgmvazeAXAC VVVfX5xQ/7f2hwrk557Ukw/jfKYtaIoayacQWWZ0fOS1Lvt68SKsWZpsljF/Vczb 0Vkc5I22Y7jMXQWXlcSAPegrLkVSflibhXG88riM9E3DkRFlFl62RcDHU2RcvihM vWNr5xPOvte7e+dONAbSSgonwV8fisood6S0nOv2y2k/lSoCO2sdUySoLHRKuOtK MF20kyA46soYRyHUGeUOo3TtmGQtOBzXhZPbPKw6M8208TkT/mmFFw6RvgmCWz1s N6EIEl1mUYh+aRyli+6q4o1HoNCRWf9UfbBf8DWTP6OoD8LDe3Ma/2kSuZBW5AeP ph/MeKrSD+5ic8ejcdebTZRaOmbF8kiciMFDSgEvI8Nf+z06w9RRilLIVXmr4+BG UplszBh65ydZ/mtoh4tBurvWlJNe788xXgG+rzyQzTbwuZKieMhSlS4THjrEIRZ6 exBBYFWGsAK0k4QskWv72LF4h9lE9S1069B/6/SntKZnBpsOBvVm9t+cHJYLJ+dL FpLJKheO7JsOO9/LbOog =HV8W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e
RE: Better SSL connector setup
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, April 10, 2013 12:09 PM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/9/13 11:54 AM, André Warnier wrote: Harris, Jeffrey E. wrote: Chris, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 09, 2013 10:01 AM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/13 8:17 AM, Harris, Jeffrey E. wrote: -Original Message- From: André Warnier [mailto:aw@ice- sa.com] Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users List Subject: Re: Better SSL connector setup Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You can improve the performance of the existing RS-232 modem pool by doing some ROT-13 and Fourier transforms prior to data encoding. However, this does require the equivalent capability on the receiving side. - -1 Using ROT-13 can certainly improve the security of your data in-transit and *is* a NIST recommendation, but it unfortunately does not improve performance as it introduces an additional operation in the pipeline. As usual, real security is a trade-off between convenience (here, speed) and actual security (the superior cipher algorithm ROT-13). I believe recent versions of OpenSSL (0.9.1c?) include the new ROT13-XOR- MD2 cipher, but since it is optimized for 8-bit processors you need to make sure to have a modern CPU -- I recommend one of the DX2 Intel processors. Okay, it does not improve performance, but it sure confuses the heck out of man-in-the-middle attacks! As for Fourier transforms, that's just security through obscurity (though it's pretty good obscurity). Fast Fourier transforms also work best with data sizes that are powers-of-two in length and so your throughput can experience odd pulsing behavior while your buffers fill waiting to be transformed. Unless you have one of the aforementioned DX2 style processors coupled with a V.22bis-capable device, you are probably not going to be able to keep up with all the traffic your Gopher server is likely to generate. Well, I was focusing on performance here, not security. And if I use my Amiga 1000, I can invoke hardware security because of the non-standard RS-232 port (just try and connect a regular RS-232 cable to that system, and see how quickly the modem shorts out!), and because the instruction set uses Motorola 68000 instructions, not DX2 Intel instructions. That's not really security either. Any common optical RS-232 isolator (like the one shown here : http://www.commfront.com/rs232-rs485-rs422-serial-converters/RS232- Iso lator-7-wire.htm) will easily overcome that issue. I started using these everywhere after I blew up the line drivers of my Soroc terminal a couple of times by forgetting to switch it off before I unplugged it. I don't know what the optical nature of the isolator does to the security by obscurity aspect though, I suspect that it may make a man-in-the-middle attack easier (as long as the man is not really in the middle physically of course). For SSL however, due to the higher bitrate, I would recommend a conversion to RS485 (with this e.g. : http://www.szatc.com/english/showpro.asp?articleid=169) (beware of embedded Trojans though). USB is just a fad. Stick with SCSI unless you want to have a whole lot of useless hardware in 18 months. Also, for your Amiga, you may want to consider swapping the 68000 processor by a 68010. It is pin-compatible and provides a significant speed boost, maybe enough to allow you to switch from a 48-bit encryption scheme to a 128-bit scheme. Don't forget to install the Microsoft High Encryption pack, or your browsers won't be able to decrypt that stuff. I think you have to register with the DOD in order to deploy ciphers of that strength. - -chris I will just convert everything into machine code. The Motorola processors and AmigaOS use Big-Endian, and Intel processes use Little-Endian, so that will just confuse anyone who uses Intel hardware and most operating systems, particularly if I just overlay the results with the Beatles' Helter Skelter played backwards and sampled at 11.025KHz. Jeffrey Harris This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy
Re: Better SSL connector setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/10/13 12:17 PM, Harris, Jeffrey E. wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, April 10, 2013 12:09 PM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/9/13 11:54 AM, André Warnier wrote: Harris, Jeffrey E. wrote: Chris, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 09, 2013 10:01 AM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/13 8:17 AM, Harris, Jeffrey E. wrote: -Original Message- From: André Warnier [mailto:aw@ice- sa.com] Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users List Subject: Re: Better SSL connector setup Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You can improve the performance of the existing RS-232 modem pool by doing some ROT-13 and Fourier transforms prior to data encoding. However, this does require the equivalent capability on the receiving side. - -1 Using ROT-13 can certainly improve the security of your data in-transit and *is* a NIST recommendation, but it unfortunately does not improve performance as it introduces an additional operation in the pipeline. As usual, real security is a trade-off between convenience (here, speed) and actual security (the superior cipher algorithm ROT-13). I believe recent versions of OpenSSL (0.9.1c?) include the new ROT13-XOR- MD2 cipher, but since it is optimized for 8-bit processors you need to make sure to have a modern CPU -- I recommend one of the DX2 Intel processors. Okay, it does not improve performance, but it sure confuses the heck out of man-in-the-middle attacks! As for Fourier transforms, that's just security through obscurity (though it's pretty good obscurity). Fast Fourier transforms also work best with data sizes that are powers-of-two in length and so your throughput can experience odd pulsing behavior while your buffers fill waiting to be transformed. Unless you have one of the aforementioned DX2 style processors coupled with a V.22bis-capable device, you are probably not going to be able to keep up with all the traffic your Gopher server is likely to generate. Well, I was focusing on performance here, not security. And if I use my Amiga 1000, I can invoke hardware security because of the non-standard RS-232 port (just try and connect a regular RS-232 cable to that system, and see how quickly the modem shorts out!), and because the instruction set uses Motorola 68000 instructions, not DX2 Intel instructions. That's not really security either. Any common optical RS-232 isolator (like the one shown here : http://www.commfront.com/rs232-rs485-rs422-serial-converters/RS232- Iso lator-7-wire.htm) will easily overcome that issue. I started using these everywhere after I blew up the line drivers of my Soroc terminal a couple of times by forgetting to switch it off before I unplugged it. I don't know what the optical nature of the isolator does to the security by obscurity aspect though, I suspect that it may make a man-in-the-middle attack easier (as long as the man is not really in the middle physically of course). For SSL however, due to the higher bitrate, I would recommend a conversion to RS485 (with this e.g. : http://www.szatc.com/english/showpro.asp?articleid=169) (beware of embedded Trojans though). USB is just a fad. Stick with SCSI unless you want to have a whole lot of useless hardware in 18 months. Also, for your Amiga, you may want to consider swapping the 68000 processor by a 68010. It is pin-compatible and provides a significant speed boost, maybe enough to allow you to switch from a 48-bit encryption scheme to a 128-bit scheme. Don't forget to install the Microsoft High Encryption pack, or your browsers won't be able to decrypt that stuff. I think you have to register with the DOD in order to deploy ciphers of that strength. - -chris I will just convert everything into machine code. The Motorola processors and AmigaOS use Big-Endian, and Intel processes use Little-Endian, so that will just confuse anyone who uses Intel hardware and most operating systems, particularly if I just overlay the results with the Beatles' Helter Skelter played backwards and sampled at 11.025KHz. Get yourself a DEC Alpha and write an algorithm that switches endian-ness halfway through the process. Good luck debugging that. - -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/ iQIcBAEBCAAGBQJRZdCoAAoJEBzwKT+lPKRYZBUQAMOkfJUZb7DieVp5sZTY1EVe
Re: Better SSL connector setup
On 4/10/2013 1:50 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/10/13 12:17 PM, Harris, Jeffrey E. wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, April 10, 2013 12:09 PM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/9/13 11:54 AM, André Warnier wrote: Harris, Jeffrey E. wrote: Chris, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 09, 2013 10:01 AM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/13 8:17 AM, Harris, Jeffrey E. wrote: -Original Message- From: André Warnier [mailto:aw@ice- sa.com] Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users List Subject: Re: Better SSL connector setup Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You can improve the performance of the existing RS-232 modem pool by doing some ROT-13 and Fourier transforms prior to data encoding. However, this does require the equivalent capability on the receiving side. - -1 Using ROT-13 can certainly improve the security of your data in-transit and *is* a NIST recommendation, but it unfortunately does not improve performance as it introduces an additional operation in the pipeline. As usual, real security is a trade-off between convenience (here, speed) and actual security (the superior cipher algorithm ROT-13). I believe recent versions of OpenSSL (0.9.1c?) include the new ROT13-XOR- MD2 cipher, but since it is optimized for 8-bit processors you need to make sure to have a modern CPU -- I recommend one of the DX2 Intel processors. Okay, it does not improve performance, but it sure confuses the heck out of man-in-the-middle attacks! As for Fourier transforms, that's just security through obscurity (though it's pretty good obscurity). Fast Fourier transforms also work best with data sizes that are powers-of-two in length and so your throughput can experience odd pulsing behavior while your buffers fill waiting to be transformed. Unless you have one of the aforementioned DX2 style processors coupled with a V.22bis-capable device, you are probably not going to be able to keep up with all the traffic your Gopher server is likely to generate. Well, I was focusing on performance here, not security. And if I use my Amiga 1000, I can invoke hardware security because of the non-standard RS-232 port (just try and connect a regular RS-232 cable to that system, and see how quickly the modem shorts out!), and because the instruction set uses Motorola 68000 instructions, not DX2 Intel instructions. That's not really security either. Any common optical RS-232 isolator (like the one shown here : http://www.commfront.com/rs232-rs485-rs422-serial-converters/RS232- Iso lator-7-wire.htm) will easily overcome that issue. I started using these everywhere after I blew up the line drivers of my Soroc terminal a couple of times by forgetting to switch it off before I unplugged it. I don't know what the optical nature of the isolator does to the security by obscurity aspect though, I suspect that it may make a man-in-the-middle attack easier (as long as the man is not really in the middle physically of course). For SSL however, due to the higher bitrate, I would recommend a conversion to RS485 (with this e.g. : http://www.szatc.com/english/showpro.asp?articleid=169) (beware of embedded Trojans though). USB is just a fad. Stick with SCSI unless you want to have a whole lot of useless hardware in 18 months. Also, for your Amiga, you may want to consider swapping the 68000 processor by a 68010. It is pin-compatible and provides a significant speed boost, maybe enough to allow you to switch from a 48-bit encryption scheme to a 128-bit scheme. Don't forget to install the Microsoft High Encryption pack, or your browsers won't be able to decrypt that stuff. I think you have to register with the DOD in order to deploy ciphers of that strength. - -chris I will just convert everything into machine code. The Motorola processors and AmigaOS use Big-Endian, and Intel processes use Little-Endian, so that will just confuse anyone who uses Intel hardware and most operating systems, particularly if I just overlay the results with the Beatles' Helter Skelter played backwards and sampled at 11.025KHz. Get yourself a DEC Alpha and write an algorithm that switches endian-ness halfway through the process. Good luck debugging that. - -chris OK, I guess I can grab a TOPS-20 emulator and write 10-bit bytes (in Algol). I don't have any PDP 8 or 10 hardware lying around any more. I do still have my PDP 8i/8L assembler manual somewhere around here (along with the appropriate DECtape). . . . . just my 10-bit cents. /mde
Re: Better SSL connector setup
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 4/8/13 8:25 PM, Martin Gainty wrote: Identification of keys and supported ciphers are an important for Key Exchange But before that happensThe certificates attributes are the only means the CA-Authority can verify the the name in the cert The certificate attributes should contain 1)1 and only 1 Hostname to contact 2)Identification information from a DN in LDAP or a suitably unique Name Service Server (ADS)allowing verification of client to a 'Name Service'http://docs.oracle.com/cd/E19575-01/820-3885/gimog/index.html Allowing your cert to authenticate to n hosts invites 2n as many potential DOS attacks Not requiring DN would negate the CA-Authority ability to verify DN CN == SSL-Host. Think of online banking and clients need to circumvent forged sites as 'The official bank site' to send your money If you are FE with Apache you will want to configure in mod-sslhttp://www.modssl.org/ Yes, you definitely want to make sure to download and install mod_ssl into your your Apache 1.3 install on your Windows NT 3.5 server. All of your Netscape clients will be able to access full 48-bit export encryption over a modern HTTP 0.9 connection. And don't forget to check that your RS-232 dial-up modem can handle the increased baud-rate necessary for the SSL-encrypted data. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Better SSL connector setup
-Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users List Subject: Re: Better SSL connector setup Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 4/8/13 8:25 PM, Martin Gainty wrote: Identification of keys and supported ciphers are an important for Key Exchange But before that happensThe certificates attributes are the only means the CA-Authority can verify the the name in the cert The certificate attributes should contain 1)1 and only 1 Hostname to contact 2)Identification information from a DN in LDAP or a suitably unique Name Service Server (ADS)allowing verification of client to a 'Name Service'http://docs.oracle.com/cd/E19575-01/820- 3885/gimog/index.html Allowing your cert to authenticate to n hosts invites 2n as many potential DOS attacks Not requiring DN would negate the CA-Authority ability to verify DN CN == SSL-Host. Think of online banking and clients need to circumvent forged sites as 'The official bank site' to send your money If you are FE with Apache you will want to configure in mod-sslhttp://www.modssl.org/ Yes, you definitely want to make sure to download and install mod_ssl into your your Apache 1.3 install on your Windows NT 3.5 server. All of your Netscape clients will be able to access full 48-bit export encryption over a modern HTTP 0.9 connection. And don't forget to check that your RS-232 dial-up modem can handle the increased baud-rate necessary for the SSL-encrypted data. You can improve the performance of the existing RS-232 modem pool by doing some ROT-13 and Fourier transforms prior to data encoding. However, this does require the equivalent capability on the receiving side. This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Re: Better SSL connector setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/13 8:17 AM, Harris, Jeffrey E. wrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users List Subject: Re: Better SSL connector setup Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 4/8/13 8:25 PM, Martin Gainty wrote: Identification of keys and supported ciphers are an important for Key Exchange But before that happensThe certificates attributes are the only means the CA-Authority can verify the the name in the cert The certificate attributes should contain 1)1 and only 1 Hostname to contact 2)Identification information from a DN in LDAP or a suitably unique Name Service Server (ADS)allowing verification of client to a 'Name Service'http://docs.oracle.com/cd/E19575-01/820- 3885/gimog/index.html Allowing your cert to authenticate to n hosts invites 2n as many potential DOS attacks Not requiring DN would negate the CA-Authority ability to verify DN CN == SSL-Host. Think of online banking and clients need to circumvent forged sites as 'The official bank site' to send your money If you are FE with Apache you will want to configure in mod-sslhttp://www.modssl.org/ Yes, you definitely want to make sure to download and install mod_ssl into your your Apache 1.3 install on your Windows NT 3.5 server. All of your Netscape clients will be able to access full 48-bit export encryption over a modern HTTP 0.9 connection. And don't forget to check that your RS-232 dial-up modem can handle the increased baud-rate necessary for the SSL-encrypted data. You can improve the performance of the existing RS-232 modem pool by doing some ROT-13 and Fourier transforms prior to data encoding. However, this does require the equivalent capability on the receiving side. - -1 Using ROT-13 can certainly improve the security of your data in-transit and *is* a NIST recommendation, but it unfortunately does not improve performance as it introduces an additional operation in the pipeline. As usual, real security is a trade-off between convenience (here, speed) and actual security (the superior cipher algorithm ROT-13). I believe recent versions of OpenSSL (0.9.1c?) include the new ROT13-XOR-MD2 cipher, but since it is optimized for 8-bit processors you need to make sure to have a modern CPU -- I recommend one of the DX2 Intel processors. As for Fourier transforms, that's just security through obscurity (though it's pretty good obscurity). Fast Fourier transforms also work best with data sizes that are powers-of-two in length and so your throughput can experience odd pulsing behavior while your buffers fill waiting to be transformed. Unless you have one of the aforementioned DX2 style processors coupled with a V.22bis-capable device, you are probably not going to be able to keep up with all the traffic your Gopher server is likely to generate. - -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/ iQIcBAEBCAAGBQJRZB84AAoJEBzwKT+lPKRY7+YQAJCHvqodBpuagJxRIR0aOr8m JJKSMyvyuiE1NFJ0Fk8X7l1yoR7MUNMmcLt7E79DZU3TaBzCxePNg68UGEOEg/u7 NDpXtBr48aYTCExszCTID1epkyu7K9HWL91KQvcCgSaReheFl8kKQg/kIXHJjpwK 4zShxZKhC7xFJ6sC92hptZkbw1a7dsgeVCE3hEWx4bOz9w5S/ejRgqyqEOgplPxg XW4JyJqyzwZjvYb9UUoWH3I7kKP5V/cuxmpzAhrXXHX/YjVcNx/pdCZSJ5bWGHXJ 20xoyhAYsSOogosYZQoRmY0IPCXVn+Ngyg8TZ3SqfXhSQAe7IPbPysp1uapGu2HR ZU0y8Xho4wlNK86Ffb4bc7g4ORgOkcZciN3YezhMNi2ipqrQ9awIWnPEewjmBUfe IgVVM0rliNgcMPRw6oe0iCnmd3kf1C2b5x+r6pFdOOdfxfYX0y919aOjywuhjqb9 Cf7cK5u9yL7qTgsr/qpoLQsMSfcVM81jPh3gISBgkwFH53rWKy/iGoMD62cA05HD 4oCyEgl7Q4SpuUq++eRIbQ/+G+2jHqX5yxpG9/0wBDbay+6qIQiWo14EZ/bYK491 YUFIXv97CbnLyGsisqB1TTo66p1psu7a3d1KLEx+0PhuZoZIGJ+/ZDQpa0aLnl0P P6ZA0lOSoifPXYnAjhGu =pYL0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Better SSL connector setup
Chris, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 09, 2013 10:01 AM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/13 8:17 AM, Harris, Jeffrey E. wrote: -Original Message- From: André Warnier [mailto:aw@ice- sa.com] Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users List Subject: Re: Better SSL connector setup Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You can improve the performance of the existing RS-232 modem pool by doing some ROT-13 and Fourier transforms prior to data encoding. However, this does require the equivalent capability on the receiving side. - -1 Using ROT-13 can certainly improve the security of your data in-transit and *is* a NIST recommendation, but it unfortunately does not improve performance as it introduces an additional operation in the pipeline. As usual, real security is a trade-off between convenience (here, speed) and actual security (the superior cipher algorithm ROT-13). I believe recent versions of OpenSSL (0.9.1c?) include the new ROT13-XOR- MD2 cipher, but since it is optimized for 8-bit processors you need to make sure to have a modern CPU -- I recommend one of the DX2 Intel processors. Okay, it does not improve performance, but it sure confuses the heck out of man-in-the-middle attacks! As for Fourier transforms, that's just security through obscurity (though it's pretty good obscurity). Fast Fourier transforms also work best with data sizes that are powers-of-two in length and so your throughput can experience odd pulsing behavior while your buffers fill waiting to be transformed. Unless you have one of the aforementioned DX2 style processors coupled with a V.22bis-capable device, you are probably not going to be able to keep up with all the traffic your Gopher server is likely to generate. Well, I was focusing on performance here, not security. And if I use my Amiga 1000, I can invoke hardware security because of the non-standard RS-232 port (just try and connect a regular RS-232 cable to that system, and see how quickly the modem shorts out!), and because the instruction set uses Motorola 68000 instructions, not DX2 Intel instructions. - -chris Jeffrey This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Re: Better SSL connector setup
Harris, Jeffrey E. wrote: Chris, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 09, 2013 10:01 AM To: Tomcat Users List Subject: Re: Better SSL connector setup -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/13 8:17 AM, Harris, Jeffrey E. wrote: -Original Message- From: André Warnier [mailto:aw@ice- sa.com] Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users List Subject: Re: Better SSL connector setup Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You can improve the performance of the existing RS-232 modem pool by doing some ROT-13 and Fourier transforms prior to data encoding. However, this does require the equivalent capability on the receiving side. - -1 Using ROT-13 can certainly improve the security of your data in-transit and *is* a NIST recommendation, but it unfortunately does not improve performance as it introduces an additional operation in the pipeline. As usual, real security is a trade-off between convenience (here, speed) and actual security (the superior cipher algorithm ROT-13). I believe recent versions of OpenSSL (0.9.1c?) include the new ROT13-XOR- MD2 cipher, but since it is optimized for 8-bit processors you need to make sure to have a modern CPU -- I recommend one of the DX2 Intel processors. Okay, it does not improve performance, but it sure confuses the heck out of man-in-the-middle attacks! As for Fourier transforms, that's just security through obscurity (though it's pretty good obscurity). Fast Fourier transforms also work best with data sizes that are powers-of-two in length and so your throughput can experience odd pulsing behavior while your buffers fill waiting to be transformed. Unless you have one of the aforementioned DX2 style processors coupled with a V.22bis-capable device, you are probably not going to be able to keep up with all the traffic your Gopher server is likely to generate. Well, I was focusing on performance here, not security. And if I use my Amiga 1000, I can invoke hardware security because of the non-standard RS-232 port (just try and connect a regular RS-232 cable to that system, and see how quickly the modem shorts out!), and because the instruction set uses Motorola 68000 instructions, not DX2 Intel instructions. That's not really security either. Any common optical RS-232 isolator (like the one shown here : http://www.commfront.com/rs232-rs485-rs422-serial-converters/RS232-Isolator-7-wire.htm) will easily overcome that issue. I started using these everywhere after I blew up the line drivers of my Soroc terminal a couple of times by forgetting to switch it off before I unplugged it. I don't know what the optical nature of the isolator does to the security by obscurity aspect though, I suspect that it may make a man-in-the-middle attack easier (as long as the man is not really in the middle physically of course). For SSL however, due to the higher bitrate, I would recommend a conversion to RS485 (with this e.g. : http://www.szatc.com/english/showpro.asp?articleid=169) (beware of embedded Trojans though). Also, for your Amiga, you may want to consider swapping the 68000 processor by a 68010. It is pin-compatible and provides a significant speed boost, maybe enough to allow you to switch from a 48-bit encryption scheme to a 128-bit scheme. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Better SSL connector setup
Identification of keys and supported ciphers are an important for Key Exchange But before that happensThe certificates attributes are the only means the CA-Authority can verify the the name in the cert The certificate attributes should contain 1)1 and only 1 Hostname to contact 2)Identification information from a DN in LDAP or a suitably unique Name Service Server (ADS)allowing verification of client to a 'Name Service'http://docs.oracle.com/cd/E19575-01/820-3885/gimog/index.html Allowing your cert to authenticate to n hosts invites 2n as many potential DOS attacks Not requiring DN would negate the CA-Authority ability to verify DN CN == SSL-Host. Think of online banking and clients need to circumvent forged sites as 'The official bank site' to send your money If you are FE with Apache you will want to configure in mod-sslhttp://www.modssl.org/ Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Date: Sun, 7 Apr 2013 11:40:24 -0700 From: its_toas...@yahoo.com To: users@tomcat.apache.org Subject: Re: Better SSL connector setup Some notes from October 2011 referenced below: On 4/7/2013 8:47 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kevin, On 4/6/13 10:10 PM, Kevin Jenkins wrote: I have a server that has two hosts: First: http://masterserver2.raknet.com/ Second (using alias) https://lobby3.raknet.com https://milestone.lobby3.raknet.com:444/ https://milestone.lobby3.raknet.com:444/ I would like have access be on these specific URLS. Right now you can use untrusted URLs, such as https://masterserver2.raknet.com/ https://milestone.lobby3.raknet.com/ Additionally, I would like to access milestone.lobby3.raknet.com on port 443 rather than 444 (so that 443 does not display a warning like it does now). I setup two connectors because I did not know how else to specify there are two ssl certificate files If you want two separate hostnames served under HTTPS and you: a. Don't have a wildcard or other special type of certificate or b. Don't have Server Name Indication capabilities From the list archives: http://mail-archives.apache.org/mod_mbox/tomcat-users/201110.mbox/%3c1318710394.66976.yahoomail...@web125511.mail.ne1.yahoo.com%3E Wildcard certificates would work in this case because the hosts are part of the same domain. SNI is apparently client-side only for Java. ...then you will need to configure a Connector for each hostname on a separate interface/port combination with separate certificates. The easiest way to do this is to set up a second interface with a separate IP address. This is usually trivial to do, and it doesn't really interfere with networking on the server. Just create a second interface with a second IP address, map DNS properly, and then set up your web server to bind specifically to the second IP address for the second hostname's SSL virtual host. In a Tomcat-only setup this is the way to go. Secondary or virtual IP addresses are easy to set up. Your Connectors look just fine (other than the use of port 444, of course). Once you have a second interface/IP, you'll want to use the address attribute of the Connector to choose the interface to listen on. I would choose one Connector to listen on *all* interfaces to be a catch-all in case your IP address(es) change(s) and you forget to re-configure everything: a security warning due to a mismatched-host is better for users than an unreachable host. - -chris The other solution is to front the Tomcat systems with an Apache HTTPD server and use named virtual hosts in SSL. Apparently the configuration checking routine throws a warning on startup, but the actual configuration works (on Apache HTTPD 2.2, I've not tried 2.4). . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Better SSL connector setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 4/8/13 8:25 PM, Martin Gainty wrote: Identification of keys and supported ciphers are an important for Key Exchange But before that happensThe certificates attributes are the only means the CA-Authority can verify the the name in the cert The certificate attributes should contain 1)1 and only 1 Hostname to contact 2)Identification information from a DN in LDAP or a suitably unique Name Service Server (ADS)allowing verification of client to a 'Name Service'http://docs.oracle.com/cd/E19575-01/820-3885/gimog/index.html Allowing your cert to authenticate to n hosts invites 2n as many potential DOS attacks Not requiring DN would negate the CA-Authority ability to verify DN CN == SSL-Host. Think of online banking and clients need to circumvent forged sites as 'The official bank site' to send your money If you are FE with Apache you will want to configure in mod-sslhttp://www.modssl.org/ Yes, you definitely want to make sure to download and install mod_ssl into your your Apache 1.3 install on your Windows NT 3.5 server. All of your Netscape clients will be able to access full 48-bit export encryption over a modern HTTP 0.9 connection. - -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/ iQIcBAEBCAAGBQJRY2bEAAoJEBzwKT+lPKRYlrEQAK9dKWMMdXDNJSb3zfHDyV5t umGfZ7JxtvClHHyBrkSIfRgnFrbnlSvYJTXC5gKP5maC9cMI9WHilIURAv/59CIs PPaV/SUPRVjHpN2HfAe6U6qN0JvqC4yKzZGwBLr5vy+KIQf5y/AkzovRLs1yVwY8 RWI4CvIUpGlT59OG+keGgTAQN2nzszIuo8kZFCw7Dl/ZK99T6HBi/NnfTNo8CX+k ACgWv4FphJO9OUfautfF2RuoZbcXOTy+DnO1Nxpa2Qew3ne6CC2CDK0+15LBK771 Pxze5rGFAGMO7M0Q/MXKHVntolpUPH5vz/1ca1qC16IO4kKjR/zkTTCAq//T3ITM 6O4Fa7r0JmDKif+I9to1CexLK8h8Bcqa7htMOAbOg9og+9kX9Xm1LKpywgsoU5Gy bfyF9jsg0VIVGZP3wXPEf2c33sUQpQ8q1Y1objefxujRWOcIvm47qjvlWVkec/Da Bn3TnmtQNPkKovp7vnwIZBeyNCkaFH803sM+x4U4exjHuykEMDLzoIhZ1+RVBkch T9Xryu1NRXPUVIxbtKgBK8upbFq0sK02aD2HEHOkszCeEHRChKimTMQyO/vvagMH Yj/vogJHEsOKpR/K6AAIxzbeEntBXmeS1EMq0XB6o0IgWM0kYlzEfJ5KBCRdnpcE He1BfzyLSJmSXp4mAZh4 =xk8T -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Better SSL connector setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kevin, On 4/6/13 10:10 PM, Kevin Jenkins wrote: I have a server that has two hosts: First: http://masterserver2.raknet.com/ Second (using alias) https://lobby3.raknet.com https://milestone.lobby3.raknet.com:444/ https://milestone.lobby3.raknet.com:444/ I would like have access be on these specific URLS. Right now you can use untrusted URLs, such as https://masterserver2.raknet.com/ https://milestone.lobby3.raknet.com/ Additionally, I would like to access milestone.lobby3.raknet.com on port 443 rather than 444 (so that 443 does not display a warning like it does now). I setup two connectors because I did not know how else to specify there are two ssl certificate files If you want two separate hostnames served under HTTPS and you: a. Don't have a wildcard or other special type of certificate or b. Don't have Server Name Indication capabilities ...then you will need to configure a Connector for each hostname on a separate interface/port combination with separate certificates. The easiest way to do this is to set up a second interface with a separate IP address. This is usually trivial to do, and it doesn't really interfere with networking on the server. Just create a second interface with a second IP address, map DNS properly, and then set up your web server to bind specifically to the second IP address for the second hostname's SSL virtual host. Your Connectors look just fine (other than the use of port 444, of course). Once you have a second interface/IP, you'll want to use the address attribute of the Connector to choose the interface to listen on. I would choose one Connector to listen on *all* interfaces to be a catch-all in case your IP address(es) change(s) and you forget to re-configure everything: a security warning due to a mismatched-host is better for users than an unreachable host. - -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/ iQIcBAEBCAAGBQJRYZUIAAoJEBzwKT+lPKRYj44P/iYRzgb3O2rjHU6fnH4xjdDf EdtuWrMIDyesjxI5DgFmkk++0R5CeIZKfD5BDlIB5wAZtM2kEMQAud/uJ/8+spkT mMAAR4LmenPB5kmXbHGznBH+DE0ih2ILt/Zq0HuYzGrDiVFDfEf/55F6R8OEYF7Z ok5ygMDPXOwrmq6lyvm8zGelcQ6yCFK8/zJkaH2+EHXHQBMmy5oVoz0OfmqN1RxN EqxpsFK9qbZVWdP5lePH4uAzjHp17W19BThxO16LOJy2teEvKDex+pHP2RLR3Pk4 nHjybAQLoM18dYtkpabOQ13537eBUbcOhvxq0BPAb1l1UJ9d22a4J8RjoPF1uUK9 hkAWDtKdqVltrSLCkowbfoVyGEPltyzqEUcP2zIg5Kn5C4cpITt4nH9OoVmrmbG0 AOMDUdJEfRurSqBGLirXxhzDnEpqFipvy1cRHrB400tnFziOLOIJtojrzmJQp+3a Z798cHthQ/2jiK7U8M5eVfsS5BzzECVI6ss8pJViWgVExoC4GNToimWoNOO0J4UZ x6bLNaf7O5fbzBS/U8tgeYjmGsnOLTOiEV/ddmPYqu1FHio4TLrk9k2k/lX5TyZF TSR0pBKggqMDeFr8dcxuXnEJTjQNT+9YyJapXfcjy3jlmzP8nVbgRb+zWM9ycuXd 9ls4z5Rw7/KsYPoEFeEp =2flM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Better SSL connector setup
Some notes from October 2011 referenced below: On 4/7/2013 8:47 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kevin, On 4/6/13 10:10 PM, Kevin Jenkins wrote: I have a server that has two hosts: First: http://masterserver2.raknet.com/ Second (using alias) https://lobby3.raknet.com https://milestone.lobby3.raknet.com:444/ https://milestone.lobby3.raknet.com:444/ I would like have access be on these specific URLS. Right now you can use untrusted URLs, such as https://masterserver2.raknet.com/ https://milestone.lobby3.raknet.com/ Additionally, I would like to access milestone.lobby3.raknet.com on port 443 rather than 444 (so that 443 does not display a warning like it does now). I setup two connectors because I did not know how else to specify there are two ssl certificate files If you want two separate hostnames served under HTTPS and you: a. Don't have a wildcard or other special type of certificate or b. Don't have Server Name Indication capabilities From the list archives: http://mail-archives.apache.org/mod_mbox/tomcat-users/201110.mbox/%3c1318710394.66976.yahoomail...@web125511.mail.ne1.yahoo.com%3E Wildcard certificates would work in this case because the hosts are part of the same domain. SNI is apparently client-side only for Java. ...then you will need to configure a Connector for each hostname on a separate interface/port combination with separate certificates. The easiest way to do this is to set up a second interface with a separate IP address. This is usually trivial to do, and it doesn't really interfere with networking on the server. Just create a second interface with a second IP address, map DNS properly, and then set up your web server to bind specifically to the second IP address for the second hostname's SSL virtual host. In a Tomcat-only setup this is the way to go. Secondary or virtual IP addresses are easy to set up. Your Connectors look just fine (other than the use of port 444, of course). Once you have a second interface/IP, you'll want to use the address attribute of the Connector to choose the interface to listen on. I would choose one Connector to listen on *all* interfaces to be a catch-all in case your IP address(es) change(s) and you forget to re-configure everything: a security warning due to a mismatched-host is better for users than an unreachable host. - -chris The other solution is to front the Tomcat systems with an Apache HTTPD server and use named virtual hosts in SSL. Apparently the configuration checking routine throws a warning on startup, but the actual configuration works (on Apache HTTPD 2.2, I've not tried 2.4). . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Better SSL connector setup
-Original Message-
From: Kevin Jenkins [mailto:rak...@jenkinssoftware.com]
Sent: Saturday, April 06, 2013 10:10 PM
To: Tomcat Users List
Subject: Better SSL connector setup
I have a server that has two hosts:
First:
http://masterserver2.raknet.com/
Second (using alias)
https://lobby3.raknet.com https://milestone.lobby3.raknet.com:444/
https://milestone.lobby3.raknet.com:444/
I would like have access be on these specific URLS. Right now you can
use untrusted URLs, such as https://masterserver2.raknet.com/
https://milestone.lobby3.raknet.com/
Additionally, I would like to access milestone.lobby3.raknet.com on
port
443 rather than 444 (so that 443 does not display a warning like it
does now).
I setup two connectors because I did not know how else to specify there
are two ssl certificate files Connector port=443
protocol=org.apache.coyote.http11.Http11AprProtocol
SSLEnabled=true
maxThreads=150 scheme=https secure=true
clientAuth=false sslProtocol=SSLv3
SSLCertificateKeyFile=${catalina.base}\conf\lobby3\privatekey.txt
SSLCertificateFile=${catalina.base}\conf\lobby3\lobby3.raknet.com.txt
/
Connector port=444
protocol=org.apache.coyote.http11.Http11AprProtocol
SSLEnabled=true
maxThreads=150 scheme=https secure=true
clientAuth=false sslProtocol=SSLv3
SSLCertificateKeyFile=${catalina.base}\conf\milestone_lobby3\privateke
y.txt
SSLCertificateFile=${catalina.base}\conf\milestone_lobby3\milestone.lo
bby3.raknet.com.txt
/
This is my host setup:
Host name=www.masterserver2.raknet.com
appBase=RakNet/masterserver2
unpackWARs=true autoDeploy=true
Aliasmasterserver2.raknet.com/Alias
Aliasmilestone.masterserver2.raknet.com/Alias
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
prefix=masterserver2.raknet.com_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
/Host
Host name=www.lobby3.raknet.com appBase=RakNet/lobby3
unpackWARs=true autoDeploy=true
Aliaslobby3.raknet.com/Alias
Aliasmilestone.lobby3.raknet.com/Alias
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
prefix=lobby3.raknet.com_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
/Host
This is not a major issue, but just cleanup. Does anyone have
suggestions?
Thanks.
You probably do not want to share one IP address between two different hosts and
certificates when using SSL. It is better to bind each host to a different IP
address, using the address attribute within each connector:
address=192.168.47.5
If each host is bound to a different IP address, then each host can use 443.
The rule is that the IP address and port combination for each host must be
different;
hosts can share either IP addresses or ports, but not both. Again, though,
with SSL,
it is better they do not share IP addresses.
I am not sure that I addressed your question of untrusted URLs, but I will
leave
that question for others on the mailing list to address if the change above
does not resolve
it.
Jeffrey Harris
This e-mail and any attachments are intended only for the use of the
addressee(s) named herein and may contain proprietary information. If you are
not the intended recipient of this e-mail or believe that you received this
email in error, please take immediate action to notify the sender of the
apparent error by reply e-mail; permanently delete the e-mail and any
attachments from your computer; and do not disseminate, distribute, use, or
copy this message and any attachments.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
