HTTPS and PERL 2

[1DMF]

Hopefully a quicky here.

If I have a HTML FORM, sitting on a HTTPS URL and it has action="

http://mydomain.com/cgiscript.cgi"

i.e. the script is not located on HTTPS URL, is the data still encrypted, or is the FORM encrypted, but the script would fall over because it cant understand it as it wasn't decrypted.

how does the interaction between HTTPS and PERL work?

Do the PERL scripts need to be on the HTTPS URL also?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[NullTerminator]

1DMF, perl is completely ignorant of HTTP/HTTPS unless you are programming at the socekt level. Talking about cgi and forms, there is no difference to perl.

The encrytption / decryption takes place at layer six of the network model in the sockets libraries, and perl is running in the application layer. The apache layer can implement the SSL translation, or it can be on another network appliance.

After the form reaches the browser from the original https url the relationship with https ends. The data in the browser is unencrytped. Other than a different URL, the browser has no knowledge of encrytion/decryption.

On the form action to http a new network session is established and sends unencrypted data to the webserver.

So to answer your question, the form is not encrypted, it is the network stream that is encrypted. A form generated from an https url can call another web page using http with no problems, or vice versa

Hope this helps

Jeb

 

[PaulTEG]

https is the protocol, which is the medium through which the data passes, form data and html, between the server and the browser. Think of SSL (TLS) as a secure tunnel between the browser and the server. Once it hits either end the data is de/en/crypted.

one of these will make it clearer than I could

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[1DMF]

Cool, so if I have the form on https and it goes to the http perl script the password and userid is secure, with out having to put all my cgi's on the https url, right?

I take it it's the same the other way round a non-secure page submits to a CGI on HTTPS and so the output is displayed securely.

Not sure what you mean about this apache thing as I am on windows hosting, does it work the same way ?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[PaulTEG]

basically you have a webserver and a browser, and two methods of communication http and https, just make sure that none of your $ENV{'HTTP_REFERER'} are coming from a "http" source otherwise the traffic is not secure.

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[1DMF]

hmm , your saying referer, but I already have a button on a page, which is HTTP and calls a scripts on HTTPS, you're saying that the comunication from browser and CGI scripts is not secure because http_referer was from HTTP not HTTPS.

but I have a script that is on http that redirects the browser to https area for PDF's , the URL in the browser shows as https, but the referer was http, your saying that this PDF is not encrypted because http_referer is not HTTPS.

how does that work showing a file on https and it not being ecrypted?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[PaulTEG]

you click a button with a https hyperlink, then when that page arrives, it's encrypted, did you check the google link in my previous post?

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[NullTerminator]

The form in the browser is not affected by https. Whether it came from https or not has no affect on how it will communicate with the server for the next page. If the action of the form is https the data will be encrypted before being sent to the server by the submit action.

Cool, so if I have the form on https and it goes to the http perl script the password and userid is secure, with out having to put all my cgi's on the https url, right?

No, the destination url must use https to be secure.

I disagree with PaulTEG regarding referer. Many non https forms collect sensitive information and forward it to third party processing sites using https. The originator of the form need not be secure, but the destination must be. It doesn't matter how the form got to your browser unless you are delivering sensitive information to the browser. Further, the referer could be blank and still submit to a https URL.

If your cgi's will collect (recieve) sensitive information, they should be protected.

Not sure what you mean about this apache thing as I am on windows hosting, does it work the same way ?

Yes windows hosting works the same way. IIS is bound to the winsock libraries which manage the SSL de/encryption. IIS manages the certificate store.

Jeb Beasley
\0

 

[1DMF]

thanks guys, so ignore http_referer, that's a red herring, because if I had a hyperlink from

HTTP://mydomain

to

HTTPS://yourdomain,

your page would be encrypted.

OK got it!

what your saying thought is if I have a form on HTTPS and submit it to a CGI script on HTTP it isn't encrypted.

but with the same essence then, if I had a form on HTTP and submit it to a cgi script on HTTPS then it will be encrypted right!

So the browser when submitting a form looks for the 'destination' URL type and if it is https, encrypts before sending, even though the form is not encrypted.

So my re-directs work, a cgi script on HTTP re-directs the browser to a HTTPS file and so that file IS encrypted.

so therefore it's the destination URL that decides encryption, right?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[1DMF]

Oh and I did look at those SSL tutorials and they suck and don't tell me anything on the questions I just asked...

http://www.wisegeek.com/what-is-ssl.htm

http://eventhelix.com/RealtimeMantra/Networking/SSL.pdf

http://www.franz.com/support/tutorials/ssl-tutorial.htm

http://code-crafters.com/abilitymailserver/tutorial_ssl.html

I gave up after looking at those 4 - sorry Paul I know you were just tying to help, but I usualy find a more acurate and understandable answer here on Tek-Tips a lot faster than hunting google for it, that's the beauty of TT's

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[NullTerminator]

You got it, exactly!

It is the destination that rules.

Jeb Beasley

 

[1DMF]

I've also found that if you have a page on HTTPS but link in code such as CSS or JS that is on HTTP, it stops the page being encrypted.

Also if the images aren't on the HTTPS you get that warning and then the page still isn't encrypted.

Personnaly I think that's stupid , why do I want the overhead of encrypting images?

But have decided, the only 100% sure way to get the page encrypted and the communication with the server, stick the whole application on HTTPS, the templates, html, pictures, javascript, perl, css, the god damn lot!

Thanks for all your help guys.

1DMF

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[NullTerminator]

The original page is still encrypted coming to the browser. It is after the browser sees the primary page that subsequent requests for images or css may be un encrypted.

The original page from the https url will definitely be encrypted. That transaction has no knowledge of subsequent requests for images, css or js.

The requests for non https resources happen after the initial https transaction has completed and the page has been parsed by the browser.

Choose what you want to protect, and put that behind the https url. Images don't need to be encrypted, but users will see the message that "although the pages is encrypted, it has links to unencrypted content" That can be disconcerting. I would say if it needs to be encrypted, limit the use of images to a minimum, and encrypt htem for a consistent user experience.

Jeb

 

[1DMF]

But if the JS & CSS isn't on HTTPS the padlock in the browser doesn't appear. - which even if technically the bit's I want encrypted actually are, to the end user the site isn't as there is no SSL padlock.

I checked with my web host and they said the page won't be encrypted / show the padlock if there are links to non-encrypted files.

And as you say that pop-up makes having non-encrypted images a non-starter.

So I guess the only choice I have is to encrypt the lot.

Thanks for all your input Jeb, it's been a great help.



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.