-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Steven M. Bellovin
Sent: 03 May 2008 00:51
To: Arcane Jill
Cc: cryptography@metzdowd.com
Subject: Re: SSL and Malicious Hardware/Software
I can't think of a great way of alerting the user,
I would
On Fri, 2 May 2008 08:33:19 +0100
Arcane Jill [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ryan Phillips
Sent: 28 April 2008 23:13
To: Cryptography
Subject: SSL and Malicious Hardware/Software
I can't think of a great
On Mon, Apr 28, 2008 at 03:12:31PM -0700, Ryan Phillips wrote:
What are people's opinions on corporations using this tactic? I can't
think of a great way of alerting the user, but I would expect a pretty
reasonable level of privacy while using an SSL connection at work.
Expectations of
On Mon, 28 Apr 2008, Ryan Phillips wrote:
| Matt's blog post [1] gets to the heart of the matter of what we can
| trust.
|
| I may have missed the discussion, but I ran across Netronome's 'SSL
| Inspector' appliance [2] today and with the recent discussion on this
| list regarding malicious
On Mon, Apr 28, 2008 at 10:03:38PM -0400, Victor Duchovni wrote:
On Mon, Apr 28, 2008 at 03:12:31PM -0700, Ryan Phillips wrote:
What are people's opinions on corporations using this tactic? I can't
think of a great way of alerting the user, but I would expect a pretty
reasonable level of
Ed Gerck wrote:
List,
I would like to address and request comments on the use of SSL/TLS and
port 587 for email security.
The often expressed idea that SSL/TLS and port 587 are somehow able to
prevent warrantless wiretapping and so on, or protect any private
communications, is IMO simply
Ed Gerck wrote, On 23/1/08 7:38 AM:
The often expressed idea that SSL/TLS and port 587 are somehow able to prevent
warrantless wiretapping and so on, or protect any private communications, is
IMO simply
not supported by facts.
I would like to see some facts to support the assertion that the
* Ed Gerck:
The often expressed idea that SSL/TLS and port 587 are somehow able
to prevent warrantless wiretapping and so on, or protect any private
communications, is IMO simply not supported by facts.
Huh? Have you got a source for that? This is he first time I've
heard of such claims.
At 10:38 AM -0800 1/22/08, Ed Gerck wrote:
The often expressed idea that SSL/TLS and port 587 are somehow able
to prevent warrantless wiretapping and so on, or protect any private
communications, is IMO simply not supported by facts.
Can you point to some sources of this often expressed idea?
On 22 January 2008 18:38, Ed Gerck wrote:
It is misleading to claim that port 587 solves the security problem of
email eavesdropping, and gives people a false sense of security. It is
worse than using a 56-bit DES key -- the email is in plaintext where it is
most vulnerable.
Well, yes:
Bodo Moeller wrote:
You don't take into account the many users these days who use wireless
Internet access from their laptop computers, typically essentially
broadcasting all network data to whoever is sufficiently close and
sufficiently nosy.
Yes. Caveats apply but SSL/TLS is useful and
On Tue, 22 Jan 2008 21:49:32 -0800
Ed Gerck [EMAIL PROTECTED] wrote:
As I commented in the
second paragraph, an attack at the ISP (where SSL/TLS is
of no help) has been the dominant threat -- and that is
why one of the main problems is called warrantless
wiretapping. Further, because US law
At 9:49 PM -0800 1/22/08, Ed Gerck wrote:
Can you point to some sources of this often expressed idea? It
seems like a pretty flimsy straw man.
It is common with those who think that the threat model is
traversing the public Internet.
I'll take that as a no.
For examples on claiming that
Steven M. Bellovin wrote:
On Tue, 22 Jan 2008 21:49:32 -0800
Ed Gerck [EMAIL PROTECTED] wrote:
As I commented in the
second paragraph, an attack at the ISP (where SSL/TLS is
of no help) has been the dominant threat -- and that is
why one of the main problems is called warrantless
wiretapping.
On Wed, 23 Jan 2008 08:10:01 -0800
Ed Gerck [EMAIL PROTECTED] wrote:
Steven M. Bellovin wrote:
On Tue, 22 Jan 2008 21:49:32 -0800
Ed Gerck [EMAIL PROTECTED] wrote:
As I commented in the
second paragraph, an attack at the ISP (where SSL/TLS is
of no help) has been the dominant threat
Steven M. Bellovin wrote:
You're confusing two concepts. Warrants apply to government
behavior; terming something a wireless wiretap carries the clear
implication of government action. Private action may or may not
violate the wiretap act or the Stored Communications Act, but it has
nothing to
On Tue, Jan 22, 2008 at 10:38:24AM -0800, Ed Gerck wrote:
List,
I would like to address and request comments on the use of SSL/TLS and port
587 for email security.
The often expressed idea that SSL/TLS and port 587 are somehow able to
prevent warrantless wiretapping and so on, or
Paul Hoffman wrote:
At 6:34 PM +0200 5/23/07, Florian Weimer wrote:
But no one is issuing certificates which are suitable for use with
SMTP (in the sense that the CA provides a security benefit).
No one? I thought that VeriSign and others did, at least a few years ago.
FWIW, last year we
On Sun, 2007-01-14 at 21:07 +0100, Erik Tews wrote:
Am Samstag, den 13.01.2007, 19:03 -0800 schrieb Richard Powell:
I was hoping someone on this list could provide me with a link to a
tool
that would enable me to dump the raw HTTP data from a web request that
uses SSL/HTTPS. I have full
On Sat, 2007-01-13 at 19:03 -0800, Richard Powell wrote:
I was hoping someone on this list could provide me with a link to a tool
that would enable me to dump the raw HTTP data from a web request that
uses SSL/HTTPS. I have full access to the server, but not to the
client, and I want to know
Thanks for the responses. I found the solution thanks to one of the
suggestions off this list.
Basically, just setup stunnel to accept the encrypted stream and forward
it to a clear server and then sniffed the stream.
Thanks again
Richard
On Sat, 2007-01-13 at 19:03 -0800, Richard Powell
Am Samstag, den 13.01.2007, 19:03 -0800 schrieb Richard Powell:
I was hoping someone on this list could provide me with a link to a
tool
that would enable me to dump the raw HTTP data from a web request that
uses SSL/HTTPS. I have full access to the server, but not to the
client, and I want
for lots of topic drift about fast transactions and lightweight SSL
(somewhat related to past assertions that majority of SSL use has been
e-commerce related)... recent post in thread on secure financial
transactions
http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high
On Tue, Jan 02, 2007 at 01:43:14PM -0500, John Ioannidis wrote:
There is too much conflicting information out there. Can someone
please recommend an SSL accelerator board that they have personally
tested and used, that works with the 2.6.* kernels and the current
release of OpenSSL, and is
On Tue, 2 Jan 2007, John Ioannidis wrote:
There is too much conflicting information out there. Can someone
please recommend an SSL accelerator board that they have personally
tested and used, that works with the 2.6.* kernels and the current
release of OpenSSL, and is actually an
, August 09, 2006 1:05 AM
To: John Gilmore
Cc: cryptography@metzdowd.com
Subject: Re: SSL Cert Prices Notes
[...]
Have you looked at StartCom?
https://cert.startcom.org/
Peter
--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
On Mon, 7 Aug 2006, John Gilmore wrote:
Here is the latest quick update on SSL Certs. It's interesting that
generally prices have risen. Though ev1servers are still the best commercial
deal out there.
The good news is that CAcert seems to be posistioned for prime time debut,
and you
John Gilmore wrote:
Date: Sun, 6 Aug 2006 23:37:30 -0700 (PDT)
From: [EMAIL PROTECTED]
Subject: SSL Cert Notes
Howdy Hackers,
Here is the latest quick update on SSL Certs. It's interesting that
generally prices have risen. Though ev1servers are still the best commercial
deal out
On Mon, Aug 07, 2006 at 05:12:45PM -0700, John Gilmore wrote:
The good news is that CAcert seems to be posistioned for prime time debut,
and you can't beat *Free*. :-)
You certainly can, if slipshod practices end up _costing_
you money.
Has CAcert stopped writing certificates with no DN
Ian G wrote:
But don't get me wrong - I am not saying that we should
carry out a world wide pogrom on SSL/PKI. What I am
saying is that once we accept that listening right now
is not an issue - not a threat that is being actively
dedended against - this allows us the wiggle room to
deploy that
On Tue, May 31, 2005 at 06:43:56PM -0400, Perry E. Metzger wrote:
|
| Ian G [EMAIL PROTECTED] writes:
| Perhaps you are unaware of it because no one has chosen to make you
| aware of it. However, sniffing is used quite frequently in cases where
| information is not properly protected. I've
Ahh-oops! That particular reply was scrappily written
late at night and wasn't meant to be sent! Apologies
belatedly, I'd since actually come to the conclusion
that Steve's statement was strictly correct, in that
we won't ever *see* sniffing because SSL is in place,
whereas I interpreted this
On Thursday 02 June 2005 11:33, Birger Tödtmann wrote:
Am Mittwoch, den 01.06.2005, 15:23 +0100 schrieb Ian G:
[...]
For an example of the latter, look at Netcraft. This is
quite serious - they are putting out a tool that totally
bypasses PKI/SSL in securing browsing. Is it insecure?
Adam Shostack wrote:
So, that may be the case when you're dealing with an SSL accelerator,
but there are lots of other cases, say, implementing daabase security
rules, or ensuring that non-transactional lookups are logged, which
are harder to argue for, take more time and energy to implement,
On Tue, May 31, 2005 at 06:43:56PM -0400, Perry E. Metzger wrote:
So we need to see a Choicepoint for listening and sniffing and so
forth.
No, we really don't.
Perhaps we do - not so much as a source of hard statistical data, but
as a source of hard pain.
People making (uninformed or
Daniel Carosone [EMAIL PROTECTED] writes:
On Tue, May 31, 2005 at 06:43:56PM -0400, Perry E. Metzger wrote:
So we need to see a Choicepoint for listening and sniffing and so
forth.
No, we really don't.
Perhaps we do - not so much as a source of hard statistical data, but
as a source of
On Wednesday 01 June 2005 10:35, Birger Tödtmann wrote:
Am Dienstag, den 31.05.2005, 18:31 +0100 schrieb Ian G:
[...]
As an alternate hypothesis, credit cards are not
sniffed and never will be sniffed simply because
that is not economic. If you can hack a database
and lift 10,000++
On Tuesday 31 May 2005 23:43, Perry E. Metzger wrote:
Ian G [EMAIL PROTECTED] writes:
Just on the narrow issue of data - I hope I've
addressed the other substantial points in the
other posts.
The only way we can overcome this issue is data.
You aren't going to get it. The companies that get
Hi Birger,
Nice debate!
On Wednesday 01 June 2005 13:52, Birger Tödtmann wrote:
Am Mittwoch, den 01.06.2005, 12:16 +0100 schrieb Ian G:
[...]
The point is this: you *could*
turn off SSL and it wouldn't make much difference
to actual security in the short term at least, and maybe
not
On Tuesday 31 May 2005 19:38, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Ian G writes:
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], James A. Donald writes:
--
PKI was designed to defeat man in the middle attacks
based on network
In message [EMAIL PROTECTED], Ian G writes:
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], James A. Donald writes:
--
PKI was designed to defeat man in the middle attacks
based on network sniffing, or DNS hijacking, which
turned out to be less of a
Ian G [EMAIL PROTECTED] writes:
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
The next part of this is circular reasoning. We don't see network
sniffing for credit card numbers *because* we have SSL.
I think you meant to write that James' reasoning is
circular, but strangely,
Steven M. Bellovin wrote:
Given the prevalance of password sniffers as early as 1993, and given
that credit card number sniffing is technically easier -- credit card
numbers will tend to be in a single packet, and comprise a
self-checking string, I stand by my statement.
the major exploits
On Tuesday 31 May 2005 21:03, Perry E. Metzger wrote:
Ian G [EMAIL PROTECTED] writes:
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
The next part of this is circular reasoning. We don't see network
sniffing for credit card numbers *because* we have SSL.
I think you meant to
Ian G [EMAIL PROTECTED] writes:
Perhaps you are unaware of it because no one has chosen to make you
aware of it. However, sniffing is used quite frequently in cases where
information is not properly protected. I've personally dealt with
several such situations.
This leads to a big issue.
On Wed, 5 Jan 2005 08:49:36 +0800, Enzo Michelangeli said:
That's basically what /dev/urandom does, no? (Except that it has the
undesirable side-effect of depleting the entropy estimate maintained
inside the kernel.)
This entropy depletion issue keeps coming up every now and then, but I
I wrote:
If the problem is a shortage of random bits, get more random bits!
Florian Weimer responded:
We are talking about a stream of several kilobits per second on a busy
server (with suitable mailing lists, of course). This is impossible
to obtain without special hardware.
Not very special, as
At 22:51 2004-12-22 +0100, Florian Weimer wrote:
* John Denker:
Florian Weimer wrote:
Would you recommend to switch to /dev/urandom (which doesn't block if
the entropy estimate for the in-kernel pool reaches 0), and stick to
generating new DH parameters for each connection,
No, I wouldn't.
* Victor Duchovni:
The third mode is quite common for STARTTLS with SMTP if I am not
mistaken. A one day sample of inbound TLS email has the following cipher
frequencies:
8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
6529(using TLSv1 with cipher
Florian Weimer wrote:
Would you recommend to switch to /dev/urandom (which doesn't block if
the entropy estimate for the in-kernel pool reaches 0), and stick to
generating new DH parameters for each connection,
No, I wouldn't.
or ...
generate them once per day and use it for several connections?
On Sun, Dec 19, 2004 at 05:24:59PM +0100, Florian Weimer wrote:
* Victor Duchovni:
The third mode is quite common for STARTTLS with SMTP if I am not
mistaken. A one day sample of inbound TLS email has the following cipher
frequencies:
8221(using TLSv1 with cipher
* Victor Duchovni:
The Debian folks have recently stumbled upon a problem in this area:
Generating the ephemeral DH parameters is expensive, in terms of CPU
cycles, but especailly in PRNG entropy. The PRNG part means that it's
not possible to use /dev/random on Linux, at least on servers.
On Wed, 1 Dec 2004, Anne Lynn Wheeler wrote:
the other attack is on the certification authorities business process
Note that in a fair number of Certificate issuing processes common in
industry the CA (sysadmin) generates both the private key -and-
certificate, signs it and then exports both
This sounds very confused. Certs are public. How would knowing a copy
of the server cert help me to decrypt SSL traffic that I have intercepted?
I found allot of people mistakenly use the term certificate to mean
something like a pkcs12 file containing public key certificate and private
key.
Anton Stiglic wrote:
I found allot of people mistakenly use the term certificate to mean
something like a pkcs12 file containing public key certificate and private
key. Maybe if comes from crypto software sales people that oversimplify or
don't really understand the technology. I don't know, but
OK, Ian and I are, rightly or wrongly, on the same page here. Obviously my
choice of the word certificate has caused confusion.
[David Wagner]
This sounds very confused. Certs are public. How would
knowing a copy
of the server cert help me to decrypt SSL traffic that I have
intercepted?
-Original Message-
From: Eric Rescorla [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 01, 2004 7:01 AM
To: [EMAIL PROTECTED]
Cc: Ben Nagy; [EMAIL PROTECTED]
Subject: Re: SSL/TLS passive sniffing
Ian Grigg [EMAIL PROTECTED] writes:
[...]
However could one do a Diffie
[EMAIL PROTECTED] writes:
-Original Message-
From: Eric Rescorla [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 01, 2004 7:01 AM
To: [EMAIL PROTECTED]
Cc: Ben Nagy; [EMAIL PROTECTED]
Subject: Re: SSL/TLS passive sniffing
Ian Grigg [EMAIL PROTECTED] writes:
[...]
However
Ben raises an interesting thought:
There was some question about whether this is possible for connections that
use client-certs, since it looks to me from the spec that those connections
should be using one of the Diffie Hellman cipher suites, which is obviously
not vulnerable to a passive
Ian Grigg writes:
I note that disctinction well! Certificate based systems
are totally vulnerable to a passive sniffing attack if the
attacker can get the key. Whereas Diffie Hellman is not,
on the face of it. Very curious...
No, that is not accurate. Diffie-Hellman is also insecure if the
Does anyone know of an SSL acceleration card that actually works under
Linux/*BSD? I've been looking at vendor web pages (AEP, Rainbow, etc), and
while they all claim to support Linux, Googling around all I find are people
saying Where can I get drivers? The ones vendor shipped only work on
Does anyone know of an SSL acceleration card that actually works under
Linux/*BSD?
I successfully used a Broadcom PCI card on a Linux (don't remember
what Linux and kernel version, this was close to 2 years ago).
If I remember correctly it was the BCM5820 processor I used
We've had great luck with the nFast and nForce lines of ssl
accelerators from nCipher under Red Hat:
http://www.ncipher.com
Depending on which model you choose, you can get anywhere from
150 to 1600 key ops/sec.
HTH,
G
--
Grant Goodale
Tom Weinstein wrote:
The economic view might be a reasonable view for an end-user to take,
but it's not a good one for a protocol designer. The protocol designer
doesn't have an economic model for how end-users will end up using the
protocol, and it's dangerous to assume one. This is
Perry E. Metzger [EMAIL PROTECTED] writes:
TLS is just a pretty straightforward well analyzed protocol for protecting a
channel -- full stop. It can be used in a wide variety of ways, for a wide
variety of apps. It happens to allow you to use X.509 certs, but if you
really hate X.509, define an
- Original Message -
From: Tom Otvos [EMAIL PROTECTED]
As far as I can glean, the general consensus in WYTM is that MITM attacks
are very low (read:
inconsequential) probability.
I'm not certain this was the consensus.
We should look at the scenarios in which this is possible, and
Internet groups starts anit-hacker initiative
http://www.computerweekly.com/articles/article.asp?liArticleID=125823liArti
cleTypeID=1liCategoryID=2liChannelID=22liFlavourID=1sSearch=nPage=1
one of the threats discussed in the above is the domain name ip-address
take-over mentioned previously
At 07:11 PM 10/22/03 -0400, Perry E. Metzger wrote:
Indeed. Imagine if we waited until airplanes exploded regularly to
design them so they would not explode, or if we had designed our first
suspension bridges by putting up some randomly selected amount of
cabling and seeing if the bridge
I'm not sure how you come to that conclusion. Simply
use TLS with self-signed certs. Save the cost of the
cert, and save the cost of the re-evaluation.
If we could do that on a widespread basis, then it
would be worth going to the next step, which is caching
the self-signed certs, and
Thor Lancelot Simon wrote:
Can you please posit an *exact* situation in which a man-in-the-middle
could steal the client's credit card number even in the presence of a
valid server certificate?
Sure. If I can assume you're talking about SSL/https as it is
typically used in ecommerce today,
Tom Otvos wrote:
As far as I can glean, the general consensus in WYTM is that MITM attacks are very
low (read:
inconsequential) probability. Is this *really* true?
The frequency of MITM attacks is very low, in the sense
that there are few or no reported occurrences. This
makes it a
So what purpose would client certificates address? Almost all of the use
of SSL domain name certs is to hide a credit card number when a consumer
is buying something. There is no requirement for the merchant to
identify and/or authenticate the client the payment infrastructure
On 10/22/2003 04:33 PM, Ian Grigg wrote:
The frequency of MITM attacks is very low, in the sense that there
are few or no reported occurrences.
We have a disagreement about the facts on this point.
See below for details.
This makes it a challenge to
respond to in any measured way.
We have a
At 05:08 PM 10/22/2003 -0400, Tom Otvos wrote:
The CC number is clearly not hidden if there is a MITM. I think the I
got my money so who cares
where it came from argument is not entirely a fair
representation. Someone ends up paying for
abuses, even if it is us in CC fees, otherwise why
Nobody doubts that it can occur, and that it *can*
occur in practice. It is whether it *does* occur
that is where the problem lies.
Or, whether it gets reported if it does occur.
The question is one of costs and benefits - how much
should we spend to defend against this attack? How
Tom Otvos wrote:
As far as I can glean, the general consensus in WYTM is that MITM
attacks are very low (read:
inconsequential) probability. Is this *really* true?
I'm not aware of any such consensus.
I suspect you'd get plenty of debate on this point.
But in any case, widespread exploitation of
Ian Grigg [EMAIL PROTECTED] writes:
Nobody doubts that it can occur, and that it *can*
occur in practice. It is whether it *does* occur
that is where the problem lies.
The question is one of costs and benefits - how much
should we spend to defend against this attack? How
much do we save
On Wed, Oct 22, 2003 at 05:08:32PM -0400, Tom Otvos wrote:
So what purpose would client certificates address? Almost all of the use
of SSL domain name certs is to hide a credit card number when a consumer
is buying something. There is no requirement for the merchant to
identify and/or
[EMAIL PROTECTED] (David Wagner) writes:
Tom Otvos wrote:
As far as I can glean, the general consensus in WYTM is that MITM
attacks are very low (read:
inconsequential) probability. Is this *really* true?
I'm not aware of any such consensus.
I will state that MITM attacks are hardly a
Tom Weinstein wrote:
Ian Grigg wrote:
Nobody doubts that it can occur, and that it *can* occur in practice.
It is whether it *does* occur that is where the problem lies.
This sort of statement bothers me.
In threat analysis, you have to base your assessment on capabilities,
not
Ian Grigg [EMAIL PROTECTED] writes:
In threat analysis, you base your assessment on
economics of what is reasonable to protect. It
is perfectly valid to decline to protect against
a possible threat, if the cost thereof is too high,
as compared against the benefits.
The cost of MITM
At 05:42 PM 10/22/2003 -0400, Tom Otvos wrote:
Absolutely true. If the only effect of a MITM is loss of privacy, then
that is certainly a
lower-priority item to fix than some quick cash scheme. So the threat
model needs to clearly
define who the bad guys are, and what their motivations are.
Ian Grigg wrote:
Tom Weinstein wrote:
In threat analysis, you have to base your assessment on capabilities,
not intentions. If an attack is possible, then you must guard against
it. It doesn't matter if you think potential attackers don't intend to
attack you that way, because you really don't
Perry E. Metzger wrote:
Ian Grigg [EMAIL PROTECTED] writes:
In threat analysis, you base your assessment on
economics of what is reasonable to protect. It
is perfectly valid to decline to protect against
a possible threat, if the cost thereof is too high,
as compared against the
Ian Grigg [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
The cost of MITM protection is, in practice, zero.
Not true! The cost is from 10 million dollars to
100 million dollars per annum. Those certs cost
money, Perry!
They cost nothing at all. I use certs every day that I've
[ Jill ]
Instead, I have a
different question: Where can I learn about SSL?
[ Ian ]
PS: next step is Ferguson Schneier's recent book
which has been described as how to re-invent SSL.
This reminds me: the best tutorial on the security
aspects of SSL 3.0 that I know of is the Counterpane
Ian Grigg [EMAIL PROTECTED] writes:
Ian Grigg [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Instead, I have a
different question: Where can I learn about SSL?
Most people seem to think the RFC is unreadable,
so ...
As in, could someone reccommend a good book, or online
Re: Eric Rescorla's SSL and TLS book:
Actually, the price should be $40 US. That's the price at Amazon.
Actually on bookpool.com it's $31. And if you can buy something else
at the same time, they have free shipping on anything over $40.
And let me 3rd or 4th the comment that it's
On Thu, Jul 10, 2003 at 12:04:33PM +0100, [EMAIL PROTECTED] wrote:
Instead, I have a
different question: Where can I learn about SSL?
As in, could someone reccommend a good book, or online tutorial, or
something, somewhere, that explains it all from pretty much first
principles, and leaves
On Thu, Jul 10, 2003 at 12:04:33PM +0100, [EMAIL PROTECTED] wrote:
guess). However, the complexity of the OpenSSL library has me stumped.
(Plus, it's Unix-centric. I'd like to turn it into a Visual Studio port so I
could compile without needing cygwin, gcc, etc., but that's another story).
It
90 matches
Mail list logo
