RE: Proxy or Firewall
OK, so how does this differ from a "man-in-the-middle" attack? Since there are two SSL sessions, there must be two session encryption keys and the proxy must be decrypting and re-encrypting everything it sees. If I'm a client, shouldn't I reject such a connection? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Dabbs Sent: Saturday, April 29, 2000 6:41 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall I believe that many enterprises that do not allow an unbroken SSL connection directly from the client throught the proxy/firewall to the remote server. This is because security policy may allows/disallow certain MIME types in the entity of the HTTP response. For this reason, SSL is "broken" at the proxy, and reestablished with a seperate SSL session between the proxy and the remote server. This is not quite as tansparent to the client, but still fairly so. The proxy is much more complicated. It is my understanding that this scheme is becoming the prevailing security strategy in large corporations, gaining favor over transparent SSL pass through. Am I wrong on this? James Dabbs James Dabbs [EMAIL PROTECTED] Director of Engineering TGA Technologies, Inc. Suite 140, 100 Pinnacle Way Norcross, GA 30071 770-441-2100 ext 126 -Original Message- From: Hansknecht, Deborah A [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 28, 2000 2:57 PM To: '[EMAIL PROTECTED]' Subject: RE: Proxy or Firewall A few comments included within... -Original Message- From: James Dabbs [mailto:[EMAIL PROTECTED]] Sent: April 28, 2000 5:37 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall ..deleted stuff HTTP over SSL, though, works transparently through almost any proxy. This is because the HTTP client knows that the proxy exists. It sets an SSL session up with the proxy, and tells the proxy to set up a seperate SSL session with the actual server. As long as requests are initiated by the client, everything is OK. Perhaps I missed some context in other messages that makes the above statements correct (and I am probably veering off-topic), but as written this is not true. HTTP works over SSL thru a proxy transparently because the client knows that a proxy exists, (that much is true) but it DOES NOT set up an SSL session. The client sends HTTPS via CONNECT which the proxy just passes on to the end server. Your standard HTTP proxy does not negotiate any SSL session with either client or server. (that is obvious if you remember that you do not need an SSL aware proxy - i.e. Apache with mod-ssl or Apache-SSL - if all you want to do is proxy HTTP or HTTPS requests.) If you are "reverse-proxying" then the proxy DOES negotiate separate SSL sessions with client and server, but that is an entirely different bucket of worms and the client browser doesn't even know that you are using a proxy. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Proxy or Firewall
PMFJI... How does one utilize something like a Cisco PIX firewall in an SSL environment? On option the firewall seems to offer is translation of network addresses, so a message that might be routed to vvv.xxx.yyy.zzz (a web-registered address) could rerouted to a private network address by the firewall. But wouldn't that cause some grief at the SSL server when it's fielding a message destined for some private network address, but it's certificate is registered for vvv.xxx.yyy.zzz and an associated domain name? Or is it only the client that is concerned with this match? TIA Harry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Nelson Sent: Monday, May 01, 2000 9:35 AM To: [EMAIL PROTECTED] Subject: Re: Proxy or Firewall On Mon, May 01, 2000 at 08:44:17AM -0600, Mike Nigbor wrote: OK, so how does this differ from a "man-in-the-middle" attack? Since there are two SSL sessions, there must be two session encryption keys and the proxy must be decrypting and re-encrypting everything it sees. If I'm a client, shouldn't I reject such a connection? It doesn't .. it actually is a man-in-the-middle attack.. however, the "attack" is being done by the corporation that writes your paycheck.. and there are very valid reasons for a company to be doing such things.. as a client, (or server) you really have no way of detecting that this is happening.. Basically, you end up w/ this picutre.. --- -- | user | --- session 1 --- | f/w | --- session 2 --- | server | --- -- Hope this helps, Tony Nelson TIS Worldwide, Firewall Admin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Dabbs Sent: Saturday, April 29, 2000 6:41 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall I believe that many enterprises that do not allow an unbroken SSL connection directly from the client throught the proxy/firewall to the remote server. This is because security policy may allows/disallow certain MIME types in the entity of the HTTP response. For this reason, SSL is "broken" at the proxy, and reestablished with a seperate SSL session between the proxy and the remote server. This is not quite as tansparent to the client, but still fairly so. The proxy is much more complicated. It is my understanding that this scheme is becoming the prevailing security strategy in large corporations, gaining favor over transparent SSL pass through. Am I wrong on this? James Dabbs James Dabbs [EMAIL PROTECTED] Director of Engineering TGA Technologies, Inc. Suite 140, 100 Pinnacle Way Norcross, GA 30071 770-441-2100 ext 126 -Original Message- From: Hansknecht, Deborah A [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 28, 2000 2:57 PM To: '[EMAIL PROTECTED]' Subject:RE: Proxy or Firewall A few comments included within... -Original Message- From: James Dabbs [mailto:[EMAIL PROTECTED]] Sent: April 28, 2000 5:37 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall ..deleted stuff HTTP over SSL, though, works transparently through almost any proxy. This is because the HTTP client knows that the proxy exists. It sets an SSL session up with the proxy, and tells the proxy to set up a seperate SSL session with the actual server. As long as requests are initiated by the client, everything is OK. Perhaps I missed some context in other messages that makes the above statements correct (and I am probably veering off-topic), but as written this is not true. HTTP works over SSL thru a proxy transparently because the client knows that a proxy exists, (that much is true) but it DOES NOT set up an SSL session. The client sends HTTPS via CONNECT which the proxy just passes on to the end server. Your standard HTTP proxy does not negotiate any SSL session with either client or server. (that is obvious if you remember that you do not need an SSL aware proxy - i.e. Apache with mod-ssl or Apache-SSL - if all you want to do is proxy HTTP or HTTPS requests.) If you are "reverse-proxying" then the proxy DOES negotiate separate SSL sessions with client and server, but that is an entirely different bucket of worms and the client browser doesn't even know that you are using a proxy. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List
Re: Proxy or Firewall
From: Tony Nelson [EMAIL PROTECTED] tnelson On Mon, May 01, 2000 at 08:44:17AM -0600, Mike Nigbor wrote: tnelson OK, so how does this differ from a "man-in-the-middle" attack? tnelson tnelson Since there are two SSL sessions, there must be two session tnelson encryption keys and the proxy must be decrypting and tnelson re-encrypting everything it sees. tnelson tnelson If I'm a client, shouldn't I reject such a connection? tnelson tnelson tnelson It doesn't .. it actually is a man-in-the-middle tnelson attack.. however, the "attack" is being done by the tnelson corporation that writes your paycheck.. and there are very tnelson valid reasons for a company to be doing such things.. as a tnelson client, (or server) you really have no way of detecting that tnelson this is happening.. I understand that some corporations choose to do that, although I do not agree with that kind of practice. What I can't understand is how it would go undetected, at least of the client or server does certificate verification (and I'm especially thinking of servers that might have a very strict check on the client certificate)... tnelson Basically, you end up w/ this picutre.. tnelson tnelson --- -- tnelson | user | --- session 1 --- | f/w | --- session 2 --- | server | tnelson --- -- -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] Member of the OpenSSL development team Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Proxy or Firewall
On Mon, May 01, 2000 at 10:16:28PM +0200, Richard Levitte - VMS Whacker wrote: From: Tony Nelson [EMAIL PROTECTED] I understand that some corporations choose to do that, although I do not agree with that kind of practice. Basically, companies do it to protect themselves.. for the very technical folks it is a pain, and they don't like it.. but we have many users that we need to protect from themselves. We also need to keep detailed logs of network traffic for legal reasons. What I can't understand is how it would go undetected, at least of the client or server does certificate verification (and I'm especially thinking of servers that might have a very strict check on the client certificate)... All that the 'man-in-the-middle' is doing is creating a dummy session.. when the server requests a client cert, the firewall will pass the request along, and the client will get it, just as the server sent it.. when the server sends the replied cert back it will forward it just as the client sent it.. Having the client or server verify remote ip's is simply impractical as most corporations hide all of their internal machines behind non-routeable ip's and masquerade at their firewall. Anything that requires ip handshaking will fail at most firewalls. By definition, 'man-in-the-middle' attacks are so deadly because they are so difficult to detect. In the case of a firewall, they are implemented as 'man-in-the-middle' on purpose. They act as a single point of control for defining network policies and logging network usage. Hope this helps. Tony -- Tony Nelson www.gnupg.org keyid 136C5B87 - Standard Disclaimers Apply - Boycott Amazon! - http://www.gnu.org/philosophy/amazon.html PGP signature
RE: Proxy or Firewall
I believe that many enterprises that do not allow an unbroken SSL connection directly from the client throught the proxy/firewall to the remote server. This is because security policy may allows/disallow certain MIME types in the entity of the HTTP response. For this reason, SSL is "broken" at the proxy, and reestablished with a seperate SSL session between the proxy and the remote server. This is not quite as tansparent to the client, but still fairly so. The proxy is much more complicated. It is my understanding that this scheme is becoming the prevailing security strategy in large corporations, gaining favor over transparent SSL pass through. Am I wrong on this? James Dabbs James Dabbs [EMAIL PROTECTED] Director of Engineering TGA Technologies, Inc. Suite 140, 100 Pinnacle Way Norcross, GA 30071 770-441-2100 ext 126 -Original Message- From: Hansknecht, Deborah A [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 28, 2000 2:57 PM To: '[EMAIL PROTECTED]' Subject: RE: Proxy or Firewall A few comments included within... -Original Message- From: James Dabbs [mailto:[EMAIL PROTECTED]] Sent: April 28, 2000 5:37 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall ..deleted stuff HTTP over SSL, though, works transparently through almost any proxy. This is because the HTTP client knows that the proxy exists. It sets an SSL session up with the proxy, and tells the proxy to set up a seperate SSL session with the actual server. As long as requests are initiated by the client, everything is OK. Perhaps I missed some context in other messages that makes the above statements correct (and I am probably veering off-topic), but as written this is not true. HTTP works over SSL thru a proxy transparently because the client knows that a proxy exists, (that much is true) but it DOES NOT set up an SSL session. The client sends HTTPS via CONNECT which the proxy just passes on to the end server. Your standard HTTP proxy does not negotiate any SSL session with either client or server. (that is obvious if you remember that you do not need an SSL aware proxy - i.e. Apache with mod-ssl or Apache-SSL - if all you want to do is proxy HTTP or HTTPS requests.) If you are "reverse-proxying" then the proxy DOES negotiate separate SSL sessions with client and server, but that is an entirely different bucket of worms and the client browser doesn't even know that you are using a proxy. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Proxy or Firewall
James Dabbs [EMAIL PROTECTED]:
I believe that many enterprises that do not allow an unbroken SSL
connection directly from the client throught the proxy/firewall to
the remote server. [...] SSL is "broken" at the proxy, and
reestablished with a seperate SSL session between the proxy and the
remote server. This is not quite as tansparent to the client, but
still fairly so. The proxy is much more complicated.
It is my understanding that this scheme is becoming the prevailing security
strategy in large corporations, gaining favor over transparent SSL pass
through. Am I wrong on this?
Which corporations do use this strategy? What proxy products of this
kind exist?
It's true that direct connections will often be impossible because
there's no internet route between the inside and the outside;
but then SOCKS or HTTP security proxies ("CONNECT ...") can be
used to let the client establish a proxied connection to the remote
host. In these scenarios the proxies *could* intercept the connections
(a man-in-the-middle attack, basically) if they fake server certificates
by acting as a CA of there own, where the CA certificate has been
installed into all the internal SSL clients. This is how products
like SafePassage work, but they are supposed to run on the local machine,
and their main purpose is to allow superior ciphersuites.
I haven't yet heard of similar programs that are meant for firewall
proxies.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: Proxy or Firewall
Boyet, Adam C wrote:
Is it possible to use Net::SSLeay and OpenSSL to make a SSL request through
a proxy or firewall.
Yes, it's possible. You must add some short code before SSL_Accept to
make connection through proxy.
If you use HTTP proxy, you may try something like this pseudocode:
SOCKET s = connect("proxy_address:proxy_port");
// write command for proxy server
write(s,"CONNECT remote_host_address:port HTTP/1.0\r\n");
write(s,"\r\n");
// read response from proxy
read(s,buffer_for_response);
// check returned HTTP status code
// read until you get CRLF CRLF (double CRLF)
// from this point it's connected to the remote host
// start SSL in normal way
SSL_set_fd(s);
SSL_Accept();
...
Michal Otoupalik ([EMAIL PROTECTED])
application/ms-tnef
Re: Proxy or Firewall
On Thu, 27 Apr 2000, Boyet, Adam C wrote: Is it possible to use Net::SSLeay and OpenSSL to make a SSL request through a proxy or firewall. SSL thru TCP-level firewalls is no problem. Cheers, Rudi __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Proxy or Firewall
Generally speaking, use of "raw" SSL through a proxy requires special setup changes in the proxy itself. Depending on the environment, this may also require a security waiver from the MIS department in charge of the proxy and a security screen on the endpoints in question. HTTP over SSL, though, works transparently through almost any proxy. This is because the HTTP client knows that the proxy exists. It sets an SSL session up with the proxy, and tells the proxy to set up a seperate SSL session with the actual server. As long as requests are initiated by the client, everything is OK. Proxies are like "internet diodes." As long as you follow their rules, everything is OK. James Dabbs [EMAIL PROTECTED] Director of Engineering TGA Technologies, Inc. Suite 140, 100 Pinnacle Way Norcross, GA 30071 770-441-2100 ext 126 -Original Message- From: Boyet, Adam C [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 27, 2000 4:18 PM To: '[EMAIL PROTECTED]' Subject: Proxy or Firewall Is it possible to use Net::SSLeay and OpenSSL to make a SSL request through a proxy or firewall. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Proxy or Firewall
-BEGIN PGP SIGNED MESSAGE- I just went through the research nessasary to program this. what actually happens is that the client connects to the http proxy, tells the http proxy where it wants to connect to, then after it is connected negotiates the SSL connection. At this point the proxy shifts into a "passthrough" mode and can no longer see the contents of the connection. The SSL is one session from end to end. David Lang On Fri, 28 Apr 2000, James Dabbs wrote: Date: Fri, 28 Apr 2000 07:36:42 -0400 From: James Dabbs [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall Generally speaking, use of "raw" SSL through a proxy requires special setup changes in the proxy itself. Depending on the environment, this may also require a security waiver from the MIS department in charge of the proxy and a security screen on the endpoints in question. HTTP over SSL, though, works transparently through almost any proxy. This is because the HTTP client knows that the proxy exists. It sets an SSL session up with the proxy, and tells the proxy to set up a seperate SSL session with the actual server. As long as requests are initiated by the client, everything is OK. Proxies are like "internet diodes." As long as you follow their rules, everything is OK. James Dabbs [EMAIL PROTECTED] Director of Engineering TGA Technologies, Inc. Suite 140, 100 Pinnacle Way Norcross, GA 30071 770-441-2100 ext 126 -Original Message- From: Boyet, Adam C [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 27, 2000 4:18 PM To: '[EMAIL PROTECTED]' Subject:Proxy or Firewall Is it possible to use Net::SSLeay and OpenSSL to make a SSL request through a proxy or firewall. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQEVAwUBOQm+vT7msCGEppcbAQF3CQf/Zf193EIMZ0H8wDiEC453MR86ceKdxl6c SBkDLvoa7RBv+C7Txh6NJFBBTzMuMFgg79KFBHxp/mf1pBPPCOc3FEQS1or7YWkj +K/GFtUv7zzW1PNaBtmuvr2CEU9MO+fio4TTE04wHZngFr95qVuC/I8s8pMKGp8H 4wky9+XdtE/QPK7uStnBdsR2omMXvYnmoTOMtRbsRUBrzl2phOF8QZrXV1ONB/h4 ZRAmtBrpoy7Vyq5o1jJ46ccaon6c0m7zcz96IxCOaT4Bhq0GoMbZbFTj6/ntp22I gbAXFmg1s9GzIu2SiFwvZyswQ8oyfZ9ykn7IVmh1Rgf3JEYCyv9fRA== =jknO -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Proxy or Firewall
A few comments included within... -Original Message- From: James Dabbs [mailto:[EMAIL PROTECTED]] Sent: April 28, 2000 5:37 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall ..deleted stuff HTTP over SSL, though, works transparently through almost any proxy. This is because the HTTP client knows that the proxy exists. It sets an SSL session up with the proxy, and tells the proxy to set up a seperate SSL session with the actual server. As long as requests are initiated by the client, everything is OK. Perhaps I missed some context in other messages that makes the above statements correct (and I am probably veering off-topic), but as written this is not true. HTTP works over SSL thru a proxy transparently because the client knows that a proxy exists, (that much is true) but it DOES NOT set up an SSL session. The client sends HTTPS via CONNECT which the proxy just passes on to the end server. Your standard HTTP proxy does not negotiate any SSL session with either client or server. (that is obvious if you remember that you do not need an SSL aware proxy - i.e. Apache with mod-ssl or Apache-SSL - if all you want to do is proxy HTTP or HTTPS requests.) If you are "reverse-proxying" then the proxy DOES negotiate separate SSL sessions with client and server, but that is an entirely different bucket of worms and the client browser doesn't even know that you are using a proxy. Proxies are like "internet diodes." As long as you follow their rules, everything is OK. James Dabbs [EMAIL PROTECTED] Director of Engineering TGA Technologies, Inc. Suite 140, 100 Pinnacle Way Norcross, GA 30071 770-441-2100 ext 126 -Original Message- From: Boyet, Adam C [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 27, 2000 4:18 PM To: '[EMAIL PROTECTED]' Subject:Proxy or Firewall Is it possible to use Net::SSLeay and OpenSSL to make a SSL request through a proxy or firewall. __ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Proxy or Firewall
No since in re-inveting the wheel. Does anyone have code that they would share? -- From: David Lang[SMTP:[EMAIL PROTECTED]] Reply To: [EMAIL PROTECTED] Sent: Friday, April 28, 2000 11:39 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall -BEGIN PGP SIGNED MESSAGE- I just went through the research nessasary to program this. what actually happens is that the client connects to the http proxy, tells the http proxy where it wants to connect to, then after it is connected negotiates the SSL connection. At this point the proxy shifts into a "passthrough" mode and can no longer see the contents of the connection. The SSL is one session from end to end. David Lang On Fri, 28 Apr 2000, James Dabbs wrote: Date: Fri, 28 Apr 2000 07:36:42 -0400 From: James Dabbs [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall Generally speaking, use of "raw" SSL through a proxy requires special setup changes in the proxy itself. Depending on the environment, this may also require a security waiver from the MIS department in charge of the proxy and a security screen on the endpoints in question. HTTP over SSL, though, works transparently through almost any proxy. This is because the HTTP client knows that the proxy exists. It sets an SSL session up with the proxy, and tells the proxy to set up a seperate SSL session with the actual server. As long as requests are initiated by the client, everything is OK. Proxies are like "internet diodes." As long as you follow their rules, everything is OK. James Dabbs [EMAIL PROTECTED] Director of Engineering TGA Technologies, Inc. Suite 140, 100 Pinnacle Way Norcross, GA 30071 770-441-2100 ext 126 -Original Message- From: Boyet, Adam C [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 27, 2000 4:18 PM To: '[EMAIL PROTECTED]' Subject: Proxy or Firewall Is it possible to use Net::SSLeay and OpenSSL to make a SSL request through a proxy or firewall. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQEVAwUBOQm+vT7msCGEppcbAQF3CQf/Zf193EIMZ0H8wDiEC453MR86ceKdxl6c SBkDLvoa7RBv+C7Txh6NJFBBTzMuMFgg79KFBHxp/mf1pBPPCOc3FEQS1or7YWkj +K/GFtUv7zzW1PNaBtmuvr2CEU9MO+fio4TTE04wHZngFr95qVuC/I8s8pMKGp8H 4wky9+XdtE/QPK7uStnBdsR2omMXvYnmoTOMtRbsRUBrzl2phOF8QZrXV1ONB/h4 ZRAmtBrpoy7Vyq5o1jJ46ccaon6c0m7zcz96IxCOaT4Bhq0GoMbZbFTj6/ntp22I gbAXFmg1s9GzIu2SiFwvZyswQ8oyfZ9ykn7IVmh1Rgf3JEYCyv9fRA== =jknO -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
