[Owasp-delhi] SSL Broken..

Gunwant Singh gunwant.s at gmail.com
Sat Jan 17 00:44:58 EST 2009


>rehashing everytime and time synch would take considerable cycles. This
organisation mite have git custom made hardware to expidiate the process
some thing like an ssl accelarater

--I am not going to care about how the organization is going to implement
this stuff. I am just curious how good this technique can be. But its
correct that this is going to be quite CPU intensive, the same way as SSL.

>But I feel like CA's it is also suceptable to collision attacks....lets say
they are using SHA-1, ans sha -1 becomes vulnerable.. bith CA and this
methodology goes down...

--Who says you can only use SHA-1/256? Changing your own implementation is
not an issue instead of changing something that everyone is using like SSL.

>when the client sends "combined has of message, password and the time-stamp"
its like sending a digital signature ...whish has to be verified
everytime....your comments....??

--Correct, the same way as we do validate Session ID each time in typical
web applications.

>One of my friend always said... if you are making code more and more
complex.. one thing is for sure you have not understood teh reuirements .
I think this falls in the same catagory instead of using simple ssl with ssl
accelarater they have complicate dthings .. what do you say?

--So the whole point is I am not comparing this with SSL in the first place.
I do not want to replace SSL with this at all. Come on, this is just a draft
proposition of a thing that may deduce something helpful or may be not. So
lets not involve what SSL can do and what this technique cannot. SSL has its
own place.

Thanks for your feedback.


On Sat, Jan 17, 2009 at 12:16 AM, Plash Chowdhary
<plash.chowdhary at tcs.com>wrote:

>
> Gunwant,
>
> rehashing everytime and time synch would take considerable cycles. This
> organisation mite have git custom made hardware to expidiate the process
> some thing like an ssl accelarater
>
>  i would say it is an innovative different approch .....
>
> But I feel like CA's it is also suceptable to collision attacks....lets say
> they are using SHA-1, ans sha -1 becomes vulnerable.. bith CA and this
> methodology goes down...
>
> (My assumption is CA keys will be as complex as combinatio of time,
> username , password and session)
>
> On second thoughs
> when the client sends "combined has of message, password and the
> time-stamp" its like sending a digital signature ...whish has to be
> verified everytime....your comments....??
>
> One of my friend always said... if you are making code more and more
> complex.. one thing is for sure you have not understood teh reuirements .
> I think this falls in the same catagory instead of using simple ssl with
> ssl accelarater they have complicate dthings .. what do you say?
>
>
> regards
> Plash
>
>
>
>  *"Gunwant Singh" <gunwant.s at gmail.com>*
>
> 01/16/2009 11:27 AM
>   To
> "Plash Chowdhary" <plash.chowdhary at tcs.com>  cc
>   Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
> Hi,
>
> Ok, let me elucidate the workings of the technique I was talking about.
>
> But before that I just want to shed some light on a few things so no-one
> comes again questioning to me about these and start some endless argument.
>
> - The e-commerce site I was talking about, I never said that they are only
> using the technique I am going to discuss. They might be using other
> techniques for their protection. What I meant was I've not seen/heard anyone
> else using this technique. That doesn't mean that they are only using this
> technique for their protection. Every giant incorporates multi-tier security
> for their resources.  I am not sure what exactly they are using besides this
> technique as Nobody reveals that.  I questioned someone on a forum, he came
> up with this technique, I studied, checked this on their documentation page,
> discussed with some people, discussed with some more, argued with even more
> and now I am here. I am looking for some feedback from you all. Just let me
> know what ever you think is wrong with this. Anyhow the question is not that
> whether they are using it or not but the question is 'How good is the
> technique?'
>
> - Please don't misinterpret my statement. I am not saying 'Don't use SSL'.
> SSL is definitely a protection mechanism for "Now" if we use it
> appropriately (CA signed certificate with a well-tested, well-reviewed
> implementation). Use SSL till someone finds some exploit *practically* not
> theoretically. This whole discussion is based on a research question so I/we
> can get a *feasible* working solution for this (may-be-a-future) problem. If
> you are not interested in discussing please do not comment. And please do
> not envisage what I am not saying.
>
> So here is how it works.
>
> No SSL. All traffic in clear text.
> Initially we need to communicate an OOB password/code/nonce (whatever you
> call it) to the client - only *once* not each time.
>
>
> 1. The client initiates a connection request to the server. As a result,
> server will initiate a handshake process to synchronize the time-stamps
> between the client and itself. Then the server will analyze tolerance time
> of packets leaving the client workstation till it reaches the server. The
> tolerance time is configured so to manage slow hosts or slow traffic. In
> plain words, server synchronizes date and time (in seconds, milliseconds or
> even nanoseconds based on the criticality of the application) with the
> client.
>
> 2. At the client side: the message, instantaneous time-stamp and the
> password are concatenated and hashed via SHA-1/SHA-256, whatever one wishes.
> This ensuing hash is combined with the username to form an authentication
> header and sent to the server.
>
> 3. At the server side, the server sees the username and perceives which
> user is trying to authenticate. Based on the tolerance configured initially
> at the handshake time, it picks the time-stamp from its own clock and using
> the password and the message it generates the hash in the same way as it was
> done at the client side.
>
> 4. If the hash matches it generates a Session ID and maps it to the
> username of the user. This Session ID will be sent from the client to the
> server along with the computed hash (which is different for each request -
> see next Step)
>
> 5. Now if the client sends another request, it appends and then hashes the
> message, password and the time-stamp (which will be apparently because of
> the different instantaneous time-stamp i.e. date and time). This resulting
> string is sent to the server along with the Session ID assigned to the user
> earlier. The resulting string contains a different hash as the time has
> changed. This will be validated at the server the same way as in Step 3.
>
> Now how can an adversary exploit this scenario? What I think of are two
> ways:
>
> 1. Either he will capture one of the hashes and try to predict the next
> hash by brute forcing different time-stamps.
>
> - But this can not be possible. He doesn't have the password to generate
> the hash.
>
> 2. What if he captures a series of requests and responses and replays them
> back to the server at a later stage.
>
> - This can't be possible either. In order to interact with the server, one
> needs to handshake so to synchronize itself with the server's clock. The
> attacker would not be able to synchronize because he would not be able to
> synchronize the *past-timestamp* (in the captured traffic) with the server's
> current time.
>
> 3. Lastly for the newbies, what if he captures the Session ID.
>
> - But he would not be able to produce the matching Hash for the request, so
> no luck.
>
> A few things to contemplate:
>
> 1. This will be considerably be CPU intensive but can be acknowledged if
> compared to the processing cycles SSL takes.
>
> 2. Time synchronization can be complex. I have no idea how to do that.
>
> 3. Please provide your
> feedback/fury/antagonism/annoyance/appreciation/whatever. Hope I explained
> this in a very straightforward way.
>
> Thanks.
>
>
>
>
>
> On Fri, Jan 16, 2009 at 4:26 AM, Plash Chowdhary <*plash.chowdhary at tcs.com
> * <plash.chowdhary at tcs.com>> wrote:
>
> Gunwant,
>
> I will be interested to know kind of soltutions are being used.
> SInce you are talking about **Time stamp**(in clear text will be
> perdictable, specially if a client side algo is being used) <some random
> number in hidden field with every request,<unique captcha with every request
> (this will be interesting)  can be a case but they will be not as roboust
>  as out of band..
> some how with Time stamps only thing that rings bell is CRYPTOGRAPHY *: D
> *(PKI??)
>
> I will be really surprized if that organization is not using SSL from a
> Vendor. (as you said its an e commerce site)
>
> and anyways i wont be using HTTPS on public content of my site and will
> switch to HTTPS session only when needed (IDEALLY)
>
>
> lemme know your thoughts
>
> Regards
> Plash
>
>
>
>
>   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
>
> 01/15/2009 12:30 PM
>
>   To
> "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
> cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
> Plash,
>
> Thanks for the idea. Please don't take my talks as overstatements, I just
> wanted to have some innovative ideas from you guys.
>
> Many organizations implement session mechanisms without using SSL. As a
> matter of fact these are not the conditions that I have set. There are many
> scenarios where using SSL is unworkable and in order to provide protection,
> there are solutions.
>
> Also, it becomes more relevant when people are trying to prove the
> weaknesses of SSL. Not to forget, facts say that most organizations who use
> SSL, use self signed certificates rather than a CA sign it.
>
> For sessions on non-SSL, there are many undocumented solutions which can be
> put into practice but such solutions needs to be well-reviewed and
> well-tested before they are implemented. I have come to know about one of
> the methods implemented by one of the top e-commerce portal giants. This
> solution is a bit tough to understand and subsequently implement it. Before
> I discuss it on the mailing list, I need to make sure that I understand it
> well. The only thing I can share at the moment is, it uses time-stamps.
> Hopefully, I would be discussing this proposition in detail in the upcoming
> Delhi Chapter meeting this month.
>
> Sorry if my talks were exaggerated. I still seek more ideas on the same
> question if someone is willing to share.
>
> Many thanks.
>
> On Thu, Jan 15, 2009 at 11:29 PM, Plash Chowdhary <*
> plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>> wrote:
>
> Gunwant,,
>
> Yes impractical "Off band validation" for each request in the conditions
> you have set. Now either you come up with a solution or im implimenting SSL
> *: )*
>
> Regards
> Plash
>   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
>
> 01/15/2009 10:27 AM
>
>   To
> "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
> cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
>
>
> I would happily accept what you say if you say how it protects.
>
> Tell me **how** would a sniffer miss your validation code on an
> unencrypted channel. We should talk about mitigating not minimizing.
>
> Oh ! unless you are saying, a different off band validation code is sent
> for **each** request - then it is possible but it is impractical even in
> high risk applications.
>
> On Thu, Jan 15, 2009 at 9:41 PM, Plash Chowdhary <*plash.chowdhary at tcs.com
> * <plash.chowdhary at tcs.com>> wrote:
>
> It does Gunwant, Use long one time off band validation....and keep a short
> TTL it will minimize the risk of relpay,....
>   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
>
> 01/15/2009 09:25 AM
>
>   To
> "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
> cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
>
>
>
>
> That doesn't affirm protection against replay attack, dude!
> In the transit, anyone can see your validation code...
> Even if you hash/encrypt it, still it can used to replay the traffic...
> this is vulnerable.. :)
>
> On Thu, Jan 15, 2009 at 3:46 AM, Plash Chowdhary <*plash.chowdhary at tcs.com
> * <plash.chowdhary at tcs.com>> wrote:
>
> verify user offline.. send an sms(or similar) with a validation code(long
> randomly genrated  string) to the user everytime he logs in to validate and
> use it everytime a transaction (high risk) is done or role is  changed..
> best way still will be to use it over SSL and use digital signatures
>
> Regards
> Plash
>   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
> Sent by: *owasp-delhi-bounces at lists.owasp.org*<owasp-delhi-bounces at lists.owasp.org>
>
> 01/14/2009 10:13 AM
>
>   To
> "Karthik Muthukrishnan" <*karthik.muthukrishnan at tcs.com*<karthik.muthukrishnan at tcs.com>
> >  cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
>
>
>
>
>
>
> Hi,
>
> Thanks for your reply but that did not answer my question. You are telling
> me what I can use for protecting the credentials. I know what I can use, but
> just out of curiousity I want to know if I don't use SSL/VPN or any other
> network based protection, what else can be done on the application layer in
> order to protect the credentials. Please see the answers below.
>
> On Wed, Jan 14, 2009 at 3:50 PM, Karthik Muthukrishnan <*
> karthik.muthukrishnan at tcs.com* <karthik.muthukrishnan at tcs.com>> wrote:
>
> > salted MD5 hashing protects the authentication credentials rightly from
> eavesdropping on the network.
> Salting is used to protect MD5 hashes from rainbow table attacks.
> Apparently Yes, although ultimately it protects authentication credentials
> only. Facts say the highest risk is eavesdropping if the session is
> unencrypted.
>
> > SSL does the same thing.
> Yes, SSL is used to ensure confidentiality and trust in the network
> communiation. Confidentiality (or prevention of network eavesdropping) is
> ensured by encryption. Trust is accomplished by Server and/or client
> certificates.
> I know what SSL does, but my question is something else.
>
> > However, in some scenarios SSL might not be feasible. For example,
> causing heavy load on the server or may be some applications don't support
> it, etc.
> In such cases SSL Accelerators are used. They are devices which can be fit
> into the architecture without changing the application or affecting the load
> on the application server.
>
> Again my question is something else. I know if SSL doesn't work,
> accelerators help expedite the processing. What I want to know is, if I "Do
> Not" want to use SSL what measures can be taken.
>
>
> > We can protect the authentication credentials using salted MD5 hashing
> or by using SSL.
> To protect authentication credentials in HTTP, we have to rely on SSL.
> Hashes are a secure (aka not in clear text) way to store authentication
> credentials.
> So you are proclaiming that we *have to* rely  on SSL- no other
> alternative.
> Hashes are also used in many applications for many different purposes
> besides authenticity and integrity.
>
>
> > In order to protect the Session credentials (Session ID, tokens,
> cookies, etc) on a non-SSL channel what measures can be taken?
> To protect either auth or session credentials we have to ensure
> confidentiality of the communication channel. If we dont use HTTPS, then VPN
> might be another option. While authentication credentials can be protected
> by some challenge handshake mechanism (similar to CHAP), we would need to
> protect session creds by encrypting the channel.
> I was asking that if we can provide some protection on the application
> level rather than on the network level. Besides SSL/VPN there are many
> options available for protecting the authentication credentials. I want to
> know (just out of curiousity) that how can we secure the session credentials
> on an unencrypted/non-SSL channel. I know this will take too much processing
> cycles, time synchronization, quantization in milliseconds even nanoseconds,
> affirmation of the key exchange, dynamic hashing key generation to mitigate
> replay attacks, and even more.
>
> I just want to know  if anyone has an idea on how it can be done if h/she
> is willing to share that would be really appreciative. Please make sure
> you understand what I am looking for.
> No offence :)
>
>
>
> Karthik
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
> _______________________________________________
> Owasp-delhi mailing list*
> **Owasp-delhi at lists.owasp.org* <Owasp-delhi at lists.owasp.org>*
> **https://lists.owasp.org/mailman/listinfo/owasp-delhi*<https://lists.owasp.org/mailman/listinfo/owasp-delhi>
>
> ForwardSourceID:NT00005236
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
>
> ForwardSourceID:NT000052F2
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
>
> ForwardSourceID:NT0000530E
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
>
> ForwardSourceID:NT0000533A
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> Gunwant Singh
>
> ForwardSourceID:NT00005482
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>


-- 
Gunwant Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090117/315afb93/attachment-0001.html 


More information about the Owasp-delhi mailing list