Re: SSL Overhead?
From: Rick Winscot (rickly_at_zyche)
Date: 08/26/04
- Next message: Fernand: "Sqlce Cab Redist License Issue"
- Previous message: Wapiti: "Re: Service Pack available?"
- In reply to: Eugene Mayevski: "Re: SSL Overhead?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 25 Aug 2004 21:23:17 -0600
Eugene,
Well... for proof then - lets refer to an msdn article which tests raw TCP,
HTTP, SOAP and several other methods of data transfer.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch14.asp
Some considerations... the performance tuning methods used to achieve better
performance (mostly on web services) is to send larger blocks of data...
which in this users case... isn't much of an option. So, we can conclude
that sending small bits of data will be very difficult to achieve high
levels of performance.
This test scenario points out three key issues that impact performance.
* amount of data
* data format
* number of users connected
It is important to note here that with each additional user the latency
roughly doubles... this holds true in each test case scenario. This can be a
concern if any data expansion causes user sessions to 'bump' into each
other. Which might be the case if you are trying to target times for sending
the data which aren't expensive...
Encryption itself isn't the sole culprit of data expansion. Using protocols
like SOAP cause expansion because of the markup... which is a common
knowledge. Web Services do markup the data heavily - and with small bits of
data can increase the amount of data sent dramatically. The real culprit
behind data expansion is the web service - and not SSL. SSL merely locks you
into the interface with data bloat as a cost of using that particular
methodology. Thus, performance is a product of the 'total system.'
Does SSL increase data size? Initial handshake...yes (and is dependent upon
the size of the key). In subsequent packets... minimally depending on the
method used (since expansion is a product of the 'total system' and not a
byproduct of encryption itself). My point however... that a simple lean
protocol and handling the encryption on the 'back-end' will out-perform your
web service / ssl recommendation hands down (somehow we digressed talking
about FUD instead of how to help this user with performance in his/her
application).
If one were to use a private 128 bit key using AES with the simple TCP
method... they (a hacker) will be reduced to brute force to access the data.
So, I don't see how your comment on security has any credence. Not to
mention that most private key methodologies... are far superior to public /
shared key systems.
PLEASE - Let us stay focused on the issue here. An app is using a GPRS
connection.... sending 5k 10 times a day. How can we improve security, be
sensitive to per byte tolls and keep data sent to an absolute minimum. My
recommendation is to move away from web services... since the total system
cost _is_designed_for_desktop_applications_. Is it any wonder why developers
moving into GPRS applications experience the same issues?
Simply delimit the data, encrypt using a private key, and use TCP to send
the data to your server - a simple token handshake will protect your
interface to prevent malicious broadcast.
This method IS secure and prevents the need for running IIS (a target for
security issues), reduces data to a minimum and in my opinion will give you
the best bang for your buck.
Cheers,
Rick Winscot
www.zyche.com
FYI: the SSL proxy / load balancing issue is a HUGE design flaw... which
exposes (human readable) encrypted data on the last step. Again, we are
probably not talking about something this complex... Perhaps you can
enlighten all of us how my proposal is insecure? As I mentioned previously -
I would be more than willing to show you how secure this simple method can
be...
"Eugene Mayevski" <mayevski@eldos.org> wrote in message
news:OV0ydLhiEHA.1104@TK2MSFTNGP10.phx.gbl...
> Hello!
> You wrote on Tue, 24 Aug 2004 13:39:21 -0600:
>
> RW> of "what are you talking about." If you are worth your salt, you will
> RW> be well aware of the specific security issues that surfaced in 2000
as
> RW> well as the general issues that continue to plague SSL systems.
>
> Such facts must be proven. While I reported certain flaws in IIS myself,
> this doesn't mean that SSL/TLS protocol has flaws in *design*. If you know
> them, name them.
>
> RW> I'd like to challenge your issue of security... and add to it economy
> RW> of exchanged data. Also - in answer of your question on what
algorithm
> RW> causes data expansion in ssl... I have to say this. All encryption
> RW> methods cause some data expansion. This can be counteracted by pre or
> RW> post compression but for small bits of data... is ineffectual. Data
> RW> expansion in encryption is a constant.
>
> Man, either you say facts or stop spreading FUD. There are no encryption
> algorithms in SSL that will double the size of WebService request.
>
> With best regards,
> Eugene Mayevski
>
- Next message: Fernand: "Sqlce Cab Redist License Issue"
- Previous message: Wapiti: "Re: Service Pack available?"
- In reply to: Eugene Mayevski: "Re: SSL Overhead?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
