I am doing some research for a school project on authentication at the
web and the risk for identity theft. How can unauthorized users misuse
your identity and get access to classified information.

For my research I have tried some programs which stops the TCP-package
with headers like HTTP/1.0 and infomation about data submitted by a
form e.g. password and username.

I have tried two web scanners:
1. Burpsuite
which I managed to intercept packeges for HTTP 1.0 and hence was able
to read inserted username and password in plaintext. Still it wasn't
able to stop SSL-traffic, although it should be able to when turning
the "Use SSL"-parameter on.
2. Nikto
which is supposed to be a great listener/scanner, but I have not been
able to make it work.

Is there any programs you would recommend which will handle SSL/TLS?
Would for instance a program like Ethereal be able to read packages
using SSL protocols?

Looking forward to your help.

royend wrote:
you want to decipher encrypted connections into plaintext ?
if that's the case ... bugger off

On 27 Okt, 18:22, goarilla <"kevin DOT paulus AT skynet DOT be">
wrote:
Wow...
not the kind of reply I was hoping for.
And no, I don't need a deciphering tool. What I want is a tool which
may scan for packages sent via SSL/TLS, like Burpsuite does with
HTTP1.0. This tool lets me read the headers (also possible to alter
them before sending them to server, but for my purpose it is only
necessary to read). Also, the project focuses on the vulnerability of
the web, and I am hoping to shove that even though SSL is implemented
the packages might be vulnerable to a Man-In-The-Middle-Attack (please
correct me if I am wrong), as the packages might be intercepted by an
attacker.

Any advice is appreciated for a tool which might help me prove it.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

royend sent the following transmission through subspace:

If someone intercepts the packages using a man-in-the-middle-attack,
the encryption will break, thus alerting the user.

You cannot intercept encrypted packages
without alerting the user that someone _IS_ intercepting them.
Because the certificate will be wrong.

- --
Solbu - http://www.solbu.net
Remove 'ugyldig.' for email
PGP key ID: 0xFA687324
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFHJAbBT1rWTfpocyQRAqGlAKCxkpbRHcfiYKUr10lkzQ 9BBC1siwCg9/fW
ZpxgxPOj+WIKQd7tmRv8fSo=
=wwlT
-----END PGP SIGNATURE-----

On 28 Okt, 04:49, Solbu <so...@ugyldig.start.no> wrote:

On 28 Okt, 11:29, Jim Watt <jimw...@aol.no_way> wrote:
That is what I thought (and hoped for...).
Can the packages be saved when intercepted and without changing the
package be used in a replay attack?

royend.

royend wrote:

i'm sorry in my native language 'pakket' has both meanings as well but still
i know the difference and the appropriate term when using them in english

On Sat, 27 Oct 2007 08:22:11 -0700, royend wrote:

Read (view) or decrypt?
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/

On 28 Okt, 22:00, Ari <arisilverst...@yahoo.com> wrote:
Basically read (view).
I guess the decryption would depend on what kind of encryption is
used, which is decided in the SSL handshake? Is it possible to somehow
decide what kind of encryption is used by viewing the encrypted text?

ALso, thanks to everyone for their contribution to this thread!

On Tue, 30 Oct 2007 00:09:20 -0000, royend wrote:

No but if you could, if the encryption is solidly applied, you should never
be able to bust it.

Ari <arisilverstein@yahoo.com> writes:

That is an idiotic statement. Had he said you canot completely and totally
trust code... it might have made sense, but we give our trust in thousands
of instances per day that are far far far less trustworthy that trusting
code. Eg, driving through a green light. It can kill you because the other
driver may not stop at a red light-- you trust him to do so. You trust him
with your life and every hour in the US that trust is broken.

No.

Unruh <unruh-spam@physics.ubc.ca> writes:

Um... no, it's not. It speaks to the depth of the wariness one
should have about code you did not completely create yourself, and how
much trust you are actually placing in something not being
backdoored.

Security is all about managing risk. And even in code you created
yourself, you're trusting the compiler... which many judge as an
acceptable risk, but to ignore that it is a risk is akin to the
ostrich sticking its head in the sand.

Best Regards,
--
Todd H.
http://www.toddh.net/

Todd H. wrote:



Better read "Reflections on reflections on trusting trust", which shows that
as long as at least one (potentially totally different) trustworthy compiler
exists, you can find a trojan horse in any other compiler. Thus, transitive
trojans are not the end of the world wrt. verification.

comphelp@toddh.net (Todd H.) writes:

As I said, had he placed a condition on his statement that "you shouldn;t
completely and utterly trust code..." his statement would have been
sensible. As it is it is idiotic. Not only can you but you both should and
need to trust much much code that you did not totally create yourself. In
fact for much code, I would trust code created by others far far more than
I would trust my own. Security is precisely about managing risk, but his
statement, as a categorical statement with no caveates is not about
managing risk, it is about being utterly and idiotically paranoid.

As I stated trust is not about absolute certainty. If it were it would not
be trust, but proof. It is about managing risk, deciding which items are
worth trusting and which not, and how much trust to place in them. It is
about suspicion tempered by needing to accomplish things. It is about
deciding how much time to devote to protection against the unforseen or the
malicious, and how much to devote to living and accomplishing something.
And his statement is about none of those things.


No it is not. It is accepting an infinitessimal level of risk. To ignore
that risk in almost all situations is the sane thing to do, and to not
ignore it is insanity in almost all situations. If the level of
consequences of malicious or other behaviour is suffuciently high ( nuclear
annihilation say) then it may be same to worry about it. In all other
situations it is almost the definition of insanity. It is as insane
as people wrapping their heads in tin foil to prevent the enemy from
reading their thoughts-- something which IS theoretically possible as well
to about the same level as Thompson's compiler trojaning.

Note that as technolgy increases, things that were insane could become
sane. For example these days wrapping your passport in tin foil is
sane behaviour.

On Sat, 03 Nov 2007 19:18:38 GMT, Unruh wrote:

Go for it, trust whatever you want.

On 03 Nov 2007 14:27:08 -0500, Todd H. wrote:

Which leaves trusting your own security which is enough of a headache.