Decrypting SSL secured packets...

[Cortexian]

Does anyone know how to go about doing anything remotely close to this without having access to the private server-side SSL key? I'm looking into this for a shady project that I'm involved with, but no one seems to know how to go about "cracking" the encryption.

If you think you could help out, send me a PM and I'll detail the project as much as I can.

[klange]

You want to crack SSL?
Hahahahahaha.

Hahaha.

Haha.

No.

[Cortexian]

You want to crack SSL?
Hahahahahaha.

Hahaha.

Haha.

No.
Anything's possible! :tinfoil:

Plus I've been reading as much as I can on cracking SSL even though I'm pretty sure it's way beyond me, but it's already been cracked and with today's PC's it would only take like 8 days to brute force a SSL key from what I've read. Maybe faster if configured properly since the articles I read were referring to single core Pentium chips, and a Core 2 Quad could probably do it a bit faster if you configured everything to make use of multi-cores.

[Phopojijo]

Not really...

That was a 40-bit key.

Current SSL keys are between 128 and 256 bits...

128-40 = 88 -- 2^88 = 309485009821345068724781056

8 days x 309485009821345068724781056 = 2475880078570760549798248448 days.

That's 6783233091974686437803421 years with the same hardware.

... hope there's a security flaw.

[RecycleBin]

http://www.novell.com/communities/node/1606/decrypting+ssl+traffic+troubleshoot+nam

Not sure if this helps or not.

[Phopojijo]

No it doesn't.

That requires you to do stuff on one of the two endpoints...

Which honestly is how real hacking is done -- compromising an endpoint

... unless there's a ridiculously simple answer to the complex question -- like in WEP's case. ((IE: The shit's broken))

... Actually I joke but it's really damn common and is REALLY hard to make something PURELY FUNDAMENTALLY secure... there could EASILY be dozens of SSL insecurities...

No-one publically knows them yet (to my knowledge -- even privately... though if someone figured it out it'd be VERY profitable to NOT say... unless they work at like -- Cisco or Microsoft.)

[RecycleBin]

I don't know shit about SSL other than it's very difficult.

Well good luck.

[Cortexian]

Ah I see, well I've already been talking to some people that I've known for awhile that work at the data center we're trying to breach. Though I've conveniently left out the part about trying to break their encryption, which I doubt will happen now since I don't have 6,783,233,091,974,686,437,803,421 years to crack the encryption and I really doubt I'll be interested in this on May 15, 6,783,233,091,974,686,437,805,430. :rolleyes:

You never know, maybe the internal contacts I have will do better than providing an SSL key and just provide us with the log on server and network system we need.

[Juan Martinez]

Mathematically, Not Possible.

But in these days, SSL is not secure I think. As you know Deep Packet Inspection, which is common
in some countries, ISP's are inspecting EVERY packet from src, dst pair to inspect someone.
In the course of this, some flaws can be seen(e.g. Message Exchange).

So In these says, I assume that IPsec packets, SSL packets are decrypted in real time.
DPI can do so many things.

The only way to avoid is that you hide your identity, for example your ip address. Then is
not possible to capture the whole packets (Too BIG) to catch you :)

[Limited]

It's been 1096 days since you first posted, hows the bruteforce going?

[Cortexian]

:effort:

[Phopojijo]

Mathematically, Not Possible.

But in these days, SSL is not secure I think. As you know Deep Packet Inspection, which is common
in some countries, ISP's are inspecting EVERY packet from src, dst pair to inspect someone.
In the course of this, some flaws can be seen(e.g. Message Exchange).

So In these says, I assume that IPsec packets, SSL packets are decrypted in real time.
DPI can do so many things.

The only way to avoid is that you hide your identity, for example your ip address. Then is
not possible to capture the whole packets (Too BIG) to catch you :)How SSL is usually broken is either by installing malware on one of the endpoints... or by compromising certificates. The connection itself is really hard to break (albeit the other aspects are easy enough to break that it doesn't usually matter).