Re: Encrypted or Not Encrypted



I totally don't understand this. Setting up a test page, firing up
wireshark and testing it all took me about 3 minutes. Instead of reading
rfcs, which evidently did not help you to get a correct answer.

What happens:

Client software renders the form. User enters the password and clicks
submit. Client looks at the action parameter of the form element and
eventually translates hostname to ip address. The action parameter also
contains schema, which in this case would be https://, so it assumes
target port would be 443. Then it initiates connection to target:443,
tcp 3-way handshake and after establishing the tcp connection, according
to schema, it initiates ssl handshake. To this point, no http traffic
was sent! - only after ssl is set up.


R.

Douglas C. Duckworth wrote:
Basha, Arif wrote:
I think Rob is talking about the difference similar to the two
following sites:

http://wachovia.com/

and

https://onlineservices.wachovia.com/auth/AuthService?action=presentLogin&url=https%3a//onlineservices.wachovia.com/NASApp/NavApp/Titanium%3faction%3dreturnHome


So if you enter the password on the first URL, is it secured on its
way to the second URL, where the SSL handshake is initiated from?




-----Original Message-----
From: listbounce@xxxxxxxxxxxxxxxxx
[mailto:listbounce@xxxxxxxxxxxxxxxxx] On Behalf Of Douglas C. Duckworth
Sent: Tuesday, September 16, 2008 12:36 PM
To: Rob
Cc: Eifrém Strinnholm Jonas; <amatachick@xxxxxxxxx>;
<security-basics@xxxxxxxxxxxxxxxxx>
Subject: Re: Encrypted or Not Encrypted

If you connect with SSL, you perform the handshake first. Thereafter
all data is encrypted. You don't send your password first. That
would make no sense since the data is viewable as plain text.
More information:

http://www.schneier.com/paper-ssl.pdf

Rob wrote:

So how are the credentials protected in network transit to the secure
site? The way you explain it, I see the creds being exposed on their
way to the secure site.

Optimally they should enter their creds after ssl has setup the
secure session, not after..

What am I missing?

Rob

Sent from my iPhone

On Sep 12, 2008, at 6:44 AM, Eifrém Strinnholm Jonas
<Jonas.Eifrem@xxxxxxxx> wrote:


Encrypted.

-----Original Message-----
From: listbounce@xxxxxxxxxxxxxxxxx
[mailto:listbounce@xxxxxxxxxxxxxxxxx] On
Behalf Of amatachick@xxxxxxxxx
Sent: den 11 september 2008 20:25
To: security-basics@xxxxxxxxxxxxxxxxx
Subject: Encrypted or Not Encrypted

I've run into this issue a few times now and would like to know what
y'all
think. Here is the situation: A website not using SSL has a login
page. As
soon as credentials are entered on this page they are redirected to
a site
using SSL. Here is a specific example of the code on one such site:

<form name="loginpersonal" method="POST"
action="https://secure.sitename.com/engine/login/login.asp";
onSubmit="return
checkLoginForm(this);">

<input type=hidden name=IsPostback value=1>



Now, from what I understand, the login credentials would still be
unencrypted while traveling to the secure site. So that would negate
the
effect of having it redirect to a secure site in the first place.
Right? I
keep brining up this fact but all I get back is that it's being
redirected
so it's secure. I feel like I'm taking crazy pills here so I'd
appreciate
some feedback. Am I wrong? If I am I can handle that, I'd just like
to know.
Thanks!




I believe it's not. The handshake requires that the client initiate the
SSL connection.

Here's an RFC for TLS:

http://tools.ietf.org/html/rfc2818

The agent acting as the HTTP client should also act as the TLS
client. It should initiate a connection to the server on the
appropriate port and then send the TLS ClientHello to begin the TLS
handshake. When the TLS handshake has finished. The client may then
initiate the first HTTP request. All HTTP data MUST be sent as TLS
"application data". Normal HTTP behavior, including retained
connections should be followed.

When you do HTTP first you are actually connecting over the wrong port
and also sending HTTP data before the handshake. You are doing the HTTP
connection first.

So perhaps after sending the password over insecure HTTP, the client is
directed to HTTPS where data between server and client are encapsulated,
but the initial password was not.
Therefore one cannot sniff the data between the client and server after
the handshake, but the initial password should be available as the SSL
handshake was not completed before sending HTTP data.
More on TLS:

http://tools.ietf.org/html/rfc5246

The TLS Record Protocol is used for encapsulation of various higher-
level protocols. One such encapsulated protocol, the TLS Handshake
Protocol, allows the server and client to authenticate each other and
to negotiate an encryption algorithm and cryptographic keys before
the application protocol transmits or receives its first byte of
data.

So don't login unless it's https.

Doug










Relevant Pages

  • Re: Encrypted or Not Encrypted
    ... Optimally they should enter their creds after ssl has setup the secure session, ... The handshake requires that the client initiate the SSL connection. ... The agent acting as the HTTP client should also act as the TLS ...
    (Security-Basics)
  • [UNIX] Alteon ACEdirector Signature/Security Bug
    ... A new security bug has been discovered in the Nortel Alteon ACEdirector ... HTTP clients could exploit it to determine the IP addresses of ostensibly ... "hidden" web servers that are load-balanced by the ACEdirector. ... uses it to persistently map a series of HTTP client requests to the same ...
    (Securiteam)
  • Alteon ACEdirector signature/security bug
    ... This is to inform you of a bug in the Nortel Alteon ACEdirector ... balance incoming HTTP requests made to one virtual IP address ... amongst the real IP addresses of multiple HTTP servers. ... series of HTTP client requests to the the same one of the real HTTP ...
    (Bugtraq)
  • Re: Firewall session disconnects after 2 minutes of inactivity
    ... I want to start by pointing out the following: HTTP keep-alives and anything ... involved in the early stage of the connection when the client downloads the ... The HOD server I mean. ... when the session takes place through the ISA Server? ...
    (microsoft.public.isa)
  • Re: Mcafee FTP Mirror Sites and ISA Server 2004 Authentication
    ... Client IP: ... Destination IP: ... Protocol: http ... Action: Failed Connection Attempt ...
    (microsoft.public.isa)