I've started to look at this in the archives and it appears the Microsoft
PFX format can't be easily manipulated with the existing OpenSSL library
functions. As it stands, my attempts to access the data fails at a call to
PKCS12_verify_mac() where the same call works for other P12 files.
Is there
> From: MacDermid, Kenny
> Sent: Wednesday, November 24, 2004 8:33 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Reverse engineering program protocol under ssl
>
>
> > From: Peter Sylvester
> >
> > http://www.rtfm.com/ssldump/
>
> Thank you for your reply Peter,
>
> Unfortunately I already looke
Ok, here's my problem. I'm using OpenSSL as part of my application, but not
all users have /dev/random (or /dev/urandom) so what's a developer to do? I
don't really want to seed with a constant string as the test apps do, but I
need a source I can count on. Asking my users aren't system administ
ct: Re:
RAND_seed()
Ok I don't know if I understood your problem correctly, but if you're
looking for ways for seeding you can always use current system time, I believe
this is pretty much available on all systems.
Hope that helps."Bibbs, Christopher"
<[EM
> From: Michael D'Errico
>
> You can try using RAND_poll() instead. It tries
> several things to gather random data. I believe
> that this is called automatically for you anyway.
If it is, it is failing because I'm getting failure to seed the PRNG errors
on my test systems that don't have /dev/
In my case, I'm trying to support various versions of Linux, AIX, Solaris,
HP-UX, Windows, and something running on OS/360 when the details finally
filter back to me. I had assumed up until a few days ago that all of the
UNIX folks had one of the /dev/random variants or that OpenSSL would fully
se
Presumably the point of this exercise is to be able to analyze normally
encrypted traffic. It would be easier to write a proxy that simply
negotiated with the server as a client and with the browser as a server.
Sure, the browser would detect that the "server" certificate was incorrect
(actually a
HTTP proxies essentially perform a pass through operation where SSL is
involved. The HTTP client issues a CONNECT command to the proxy and then
acts as if it is in direct contact with the SSL host. The proxy doesn't try
to read or manipulate the request/reply pairs.
> -Original Message-
