Re: [MiNT] Libcurl-ssl / RPM package

[Paul Wratt <paul.wratt@gmail.com>]

2010/6/15 m0n0 <ole@monochrom.net>:
>
> Am Montag, den 14.06.2010, 22:49 +0200 schrieb m0n0 <ole@monochrom.net>:
>> I just tested SSLv2 with curl. It's seems to work fast... It works out
> ok.
>> :)
>> But when using SSLv3 it waits forever... :( So it seems to be an issue
>> with SSLv3 ... but I expect SSLv3 is what most servers require.
>
> I tried SSLv3 with an other page, that also seems to work fast enough. It
> seems that the https URL I tried (https://webmailer.hosteurope.de) is
> causing problems...
>
I think you have found your major: "not all servers are created equal"

The rest of this post is simply to round of this thread, for readers
in years to come..

RE: SSLv2 vs SSLv3

this is what the wiki has to say:
"SSL v3 improved upon SSL v2 by adding SHA-1 based ciphers, and
support for certificate authentication. Additional improvements in SSL
v3 include better handshake protocol flow and increased resistance to
man-in-the-middle attacks"

this is what it says about SSL:
"The SSL protocol was originally developed by Netscape. Version 1.0
was never publicly released; version 2.0 was released in February 1995
but "contained a number of security flaws which ultimately led to the
design of SSL version 3.0". (Rescorla 2001) SSL version 3.0 was
released in 1996."

I think the following is linked to the above, and your specific
problem (from OpenSSL mail-list):
""
I have been using openssl 0.9.6 under windows and have found some
behaviour that I find curious.  When I change the suite from V2 to V3 I
am getting an enormous performance hit.

SSL_METHOD * pMethod = SSLv2_client_method();

SSL connection using : RC4-MD5
Peer name SSLeay demo server
2113863 bytes written
In 0.36 seconds

and

SSL_METHOD * pMethod = SSLv3_client_method();

SSL connection using : RC4-MD5
Peer name SSLeay demo server
2113863 bytes written
In 25.797 seconds

""


RE: SSL on m68k

I believe the reason for the initial (usable) versions of OpenSSL
ports to m68k platforms being FPU specific are obvious, as both Ole
and Vincent have expained (from different ends).

The fact is that SSL is maths intensive, and therefore, in order to be
useful on these lowspec (m68k) platforms, it was immediately apparent
that compiling with an FPU was mandatory is order to make it usable
(which it appears to be)

I would therefore be interested to see what was possible with 030 &
060 without FPU, as there are "standard" machines out there without
FPU's, however I dont think they are in very wide use.

The reason I ask this, is because of overclocked CTx 060 cpu's where
the FPU is unstable, even thought the CPU may not be.

This may be a good enough reason for someone to supply (in this
example) non-FPU enabled binaries of SSL and libs based on SSL

This is not an issue in general, which is obviously why the special
CPU option: -m68020-60 is the standard target, which suggests it is
impractical to create later versions of GCC binaries without FPU usage
(there is just too much maths going on for what appears to be a slow
CPU target anyway, a plain 68000)

Off the top of my head I cannot remember exactly how this impacts the
use of CF v4e, but I think the issues are dealt with because it is a
finite solution, ie there is no (full) v4e support where the target
may get unsupported instructions.



Last bits:

There is a benefit in the issue with SSL requiring FPU support, in
that there is the opportunity to maintain 68000 support where SSL is
not needed

As much as I would hate to do the actual full install process of
Gentoo (from source), it is becoming more an more attractive for
specific hardware combinations, as outlined above.

It would be interesting to see if there was a practical way (read
fast) of compiling distributions for Atari platforms using modern
hardware and cross-compiling, where the OS does ONLY that, the
creation of the binary distro, with no desktop, no/limited services,
no X running, no extra kernel interfaces, etc, just enough to run
make/configure/gcc (or other compiling processes)


Paul