RE: Better SSL connector setup

2013-04-11 Thread Esmond Pitt
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

2013-04-10 Thread Mark Eggers

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 

Re: Better SSL connector setup

2013-04-10 Thread Christopher Schultz
-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 

RE: Better SSL connector setup

2013-04-10 Thread Harris, Jeffrey E.


> -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.

Re: Better SSL connector setup

2013-04-10 Thread Christopher Schultz
-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/

iQIcBAEBCAAG

Re: Better SSL connector setup

2013-04-09 Thread André Warnier

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

2013-04-09 Thread Harris, Jeffrey E.
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

2013-04-09 Thread Christopher Schultz
-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

2013-04-09 Thread Harris, Jeffrey E.


> -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

2013-04-09 Thread André Warnier

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

2013-04-08 Thread Christopher Schultz
-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

2013-04-08 Thread Martin Gainty
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  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  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  to choose the interface to
> > listen on. I would choose one  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

2013-04-07 Thread Mark Eggers

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/

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  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  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  to choose the interface to
listen on. I would choose one  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

2013-04-07 Thread Christopher Schultz
-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/
> 
> 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  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  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  to choose the interface to
listen on. I would choose one  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

2013-04-06 Thread Harris, Jeffrey E.


> -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/
>
> 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  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"
> />
>
>  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:
>  appBase="RakNet/masterserver2"
> unpackWARs="true" autoDeploy="true">
> masterserver2.raknet.com
> milestone.masterserver2.raknet.com
>  directory="logs"
>prefix="masterserver2.raknet.com_access_log." suffix=".txt"
>pattern="%h %l %u %t "%r" %s %b" />
>   
>  unpackWARs="true" autoDeploy="true">
> lobby3.raknet.com
> milestone.lobby3.raknet.com
>  directory="logs"
>prefix="lobby3.raknet.com_access_log." suffix=".txt"
>pattern="%h %l %u %t "%r" %s %b" />
>   
>
> 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