You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Mark McCulligh <mm...@visualtech.ca> on 2006/02/06 21:34:53 UTC

[users@httpd] SSL / HTML question

If you have a login html (http://www.ex.com/login.html) where the <form> 
action is to a https website (https://www.ex2.com/login_script.php).  
Will the login information be submitted encrypted. Or does the user 
first have to be on to the secure website before loggin in?

Just wondering when you go from http(80) to https(443) when does the 
data start to be secured?

Thanks,
Mark.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SSL / HTML question

Posted by Joshua Slive <jo...@slive.ca>.
On 2/6/06, Mark McCulligh <mm...@visualtech.ca> wrote:

> I think I now understanding the attack.  They are changing the response
> information when the login form is being sent to the user in plain
> text.

Yep.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SSL / HTML question

Posted by Mark McCulligh <mm...@visualtech.ca>.
Joshua Slive wrote:

>On 2/6/06, Mark McCulligh <mm...@visualtech.ca> wrote:
>  
>
>>This type of attack can be pulled off even if the login form is secured.
>>The attacker just has create a login page that looks like mine and get
>>the user to use it.  A lot of users won't realize they are on the wrong
>>website and the lock(secure) is missing.  We have all seen those Paypal
>>emails that try and get you to click on the link and login.
>>    
>>
>
>Yes, it is easy to fool the average user.  The difference with the
>man-in-the-middle attack is that it would fool a relatively
>sophisticated user.  There is essentially no way to tell your info is
>about to be stolen unless you view-source and analyze the code.  For
>the other attacks you mention, a quick look at the URL bar will tell
>the story.  (But I agree that most users don't even bother to do
>that.)
>  
>
I think I now understanding the attack.  They are changing the response 
information when the login form is being sent to the user in plain 
text.  I first thought you where telling me the attacker was getting the 
user to go to a different URL and log in.

Mark.

>Joshua.
>
>---------------------------------------------------------------------
>The official User-To-User support forum of the Apache HTTP Server Project.
>See <URL:http://httpd.apache.org/userslist.html> for more info.
>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>   "   from the digest: users-digest-unsubscribe@httpd.apache.org
>For additional commands, e-mail: users-help@httpd.apache.org
>
>  
>


-- 
___________________________________________
Mark McCulligh, Web Consultant
VisualTech Components www.VisualTech.ca
mmcculli@visualtech.ca
(519)318-7905


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SSL / HTML question

Posted by Joshua Slive <jo...@slive.ca>.
On 2/6/06, Mark McCulligh <mm...@visualtech.ca> wrote:
>
> This type of attack can be pulled off even if the login form is secured.
> The attacker just has create a login page that looks like mine and get
> the user to use it.  A lot of users won't realize they are on the wrong
> website and the lock(secure) is missing.  We have all seen those Paypal
> emails that try and get you to click on the link and login.

Yes, it is easy to fool the average user.  The difference with the
man-in-the-middle attack is that it would fool a relatively
sophisticated user.  There is essentially no way to tell your info is
about to be stolen unless you view-source and analyze the code.  For
the other attacks you mention, a quick look at the URL bar will tell
the story.  (But I agree that most users don't even bother to do
that.)

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SSL / HTML question

Posted by Mark McCulligh <mm...@visualtech.ca>.
Joshua Slive wrote:

>On 2/6/06, Mark McCulligh <mm...@visualtech.ca> wrote:
>  
>
>>The client should alway be logging
>>in on their website for I hope they reallize if they where not on their
>>website.
>>    
>>
>
>I'm not sure if you understood or not, but my point was that a
>man-in-the-middle could make it look exactly like they were on their
>own site.  He could simply replace the target URL on the form to point
>to his own site.  (If you checked the URL-bar, you might see
>after-the-fact that you had gone to the wrong site.  But the data
>would already be stolen.)
>  
>
I think you misunderstood my reply.  I was just trying to explain my setup.

This type of attack can be pulled off even if the login form is secured. 
The attacker just has create a login page that looks like mine and get 
the user to use it.  A lot of users won't realize they are on the wrong 
website and the lock(secure) is missing.  We have all seen those Paypal 
emails that try and get you to click on the link and login.

Mark.

>Joshua.
>
>---------------------------------------------------------------------
>The official User-To-User support forum of the Apache HTTP Server Project.
>See <URL:http://httpd.apache.org/userslist.html> for more info.
>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>   "   from the digest: users-digest-unsubscribe@httpd.apache.org
>For additional commands, e-mail: users-help@httpd.apache.org
>
>  
>


-- 
___________________________________________
Mark McCulligh, Web Consultant
VisualTech Components www.VisualTech.ca
mmcculli@visualtech.ca
(519)318-7905


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SSL / HTML question

Posted by Joshua Slive <jo...@slive.ca>.
On 2/6/06, Mark McCulligh <mm...@visualtech.ca> wrote:
> The client should alway be logging
> in on their website for I hope they reallize if they where not on their
> website.

I'm not sure if you understood or not, but my point was that a
man-in-the-middle could make it look exactly like they were on their
own site.  He could simply replace the target URL on the form to point
to his own site.  (If you checked the URL-bar, you might see
after-the-fact that you had gone to the wrong site.  But the data
would already be stolen.)

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SSL / HTML question

Posted by Mark McCulligh <mm...@visualtech.ca>.
Joshua Slive wrote:

>On 2/6/06, Mark McCulligh <mm...@visualtech.ca> wrote:
>  
>
>>If you have a login html (http://www.ex.com/login.html) where the <form>
>>action is to a https website (https://www.ex2.com/login_script.php).
>>Will the login information be submitted encrypted. Or does the user
>>first have to be on to the secure website before loggin in?
>>
>>Just wondering when you go from http(80) to https(443) when does the
>>data start to be secured?
>>    
>>
>
>Each request is independent.  So when the user hits the "POST" button,
>a new request is started to the https server that will carry the data
>encrypted.
>But this scheme is subject to man-in-the-middle attacks.  An attacker
>with access to the wire could replace login.html with his own page
>that looks the same but directs the POST to his own server.   So
>unless you have users that always carefully examine the web page
>source code, you should make the form ecrypted as well.
>  
>
Thanks Joshua, just what I wanted to know.

In short what I am doing is I have a couple static websites and one 
secure website they can login in to manage their website. The clients 
want the login form on their website and I don't what to purchase 
multiple SSL just for the login form. The client should alway be logging 
in on their website for I hope they reallize if they where not on their 
website. But as we all know users can be stupid or though emails ask you 
to click here to verify your credit card wouldn't still be out there.

Mark.

>Joshua.
>
>---------------------------------------------------------------------
>The official User-To-User support forum of the Apache HTTP Server Project.
>See <URL:http://httpd.apache.org/userslist.html> for more info.
>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>   "   from the digest: users-digest-unsubscribe@httpd.apache.org
>For additional commands, e-mail: users-help@httpd.apache.org
>
>  
>


-- 
___________________________________________
Mark McCulligh, Web Consultant
VisualTech Components www.VisualTech.ca
mmcculli@visualtech.ca
(519)318-7905


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] SSL / HTML question

Posted by Joshua Slive <jo...@slive.ca>.
On 2/6/06, Mark McCulligh <mm...@visualtech.ca> wrote:
> If you have a login html (http://www.ex.com/login.html) where the <form>
> action is to a https website (https://www.ex2.com/login_script.php).
> Will the login information be submitted encrypted. Or does the user
> first have to be on to the secure website before loggin in?
>
> Just wondering when you go from http(80) to https(443) when does the
> data start to be secured?

Each request is independent.  So when the user hits the "POST" button,
a new request is started to the https server that will carry the data
encrypted.

But this scheme is subject to man-in-the-middle attacks.  An attacker
with access to the wire could replace login.html with his own page
that looks the same but directs the POST to his own server.   So
unless you have users that always carefully examine the web page
source code, you should make the form ecrypted as well.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org