To what extent, if at all, are HTTPS headers encrypted?
They are encrypted in transit through SSL. There is no special encryption dedicated to headers, HTTPS encrypts the entire message.
All headers are encrypted in HTTPS. You may want to look at some documentation on how SSL and TLS work.
SSL sets up a private authenticated link to the server and then sends an http request over that link. The evil-doer snooping on the link cant actually tell from just watching the connection that http is being used. SSL its self has some unencrypted headers that it uses to establish this connection though these should not be confused with the headers that are part of the http protocol.
Related
Is it possible to have a Sinatra web server detect an HTTPS:// connection and redirect it to a HTTP:// connection with the same URL, and not have to deal with SSL certificates? I tried stunnel to redirect but it's asking for a cert.
With HTTPS, the first thing a browser does is to create a secure connection to the webserver. For this, it requires a valid server certificate. Before the secure connection is established, you can not perform any HTTP redirect yet.
Thus, to be able to perform any redirects from https to http, you need to have a valid SSL certificate on the server. And in that case, you should really think about having SSL enabled for all content anyway.
Is the data secure if posted programmatically (not through a browser) to an https endpoint?
My understanding is browser encrypts data and sends it to https endpoint. How can a Ruby or Node.js or any other program do the same?
Yes. If you connect to an https endpoint with curl, wget, or whatever library, the transfer is secure from the source of the connection to the destination. That source could be a server (your webserver) or the client browser.
However, if it's done in client side JS or other browser scripting language, you have to make sure the initial request from client to your site is secure as well if first passing secure data to the client for it to pass to the destination https server.
I checked node.js request library as well as Ruby HTTParty libraries. Both these support SSL encryption based on proper options (port: 443 etc.). In general if we use any well supported library that enables HTTP gets and posts, we should be covered in terms of transmitting data securely to the https endpoint.
I think I understand what you mean and that question has been answered. However, I would just point out that HTTPS does not make your data secure, only the connection and even that is only encrypted from eavesdropping which is not really secure.
There is, of course, lots more to think about and do to make your data secure end-to-end.
What additional changes are required to make this simple HTTP header to speak to a HTTPS enabled server.
GET /index.php HTTP/1.1
Host: localhost
[CR]
[CR]
EDIT
To add some context, all I'm trying to do is open a TCP port (443) and read the index page but the server seems to return a 400 - Bad request along with a message that goes "You're speaking plain HTTP to an SSL-enabled server port." I thought this probably meant altering the header in some fashion.
HTTP runs on top of secured channel. No adjustments are needed at all on HTTP level. You need to encrypt the whole traffic going to the socket (after it leaves HTTP client code) and decrypt the traffic coming from the socket before it reaches HTTP client.
You encrypt the payload with the information from the server to encrypt. This is done via handshake on a server by server basis, so you can't just fake it once have it work everywhere.
The payload includes the query string, cookies, form, etc.
How does the browser figure out the destination in an HTTPS connection? All the headers are encrypted..
Update:No this is not a homework.. my name is student because I'll always be learning in this HUGE awesome field
When a browser views an url like https://www.gmail.com/ first thing your browser does is resolves www.gmail.com to 72.14.213.19.
Next your browser opens up a TCP connection to 72.14.213.19 on port 443.
The browser & server before ANY headers are transmitted negotiate a public key encryption scheme (RSA) based on the SSL Certificate that is digitally signed.
In this process the browser checks the certificate authenticity before communicating.
Once this trust between client & server has been established, the client now can encrypt the headers in a way the server can decrypt. It proceeds to make the HTTP request inside the SSL Tunnel.
The server decrypts the message, serves the request and encrypts it in a way that that particular client can decrypt.
The browser then decrypts the response, reads the headers and makes decisions about how to proceed from there.
This has been an overview of an HTTPS connection event. :D
The string containing https: that you typed in the browser is what the browser uses. That is not encrypted,
Probably more than you'd ever want or need to know about the The First Few Milliseconds of an HTTPS Connection I'd go into more detail explaining stuff if your username wasn't student, and this wasn't likely homework.
My understanding is that TLS is an encryption technique that allowing two STMP servers to communicate with each other securely. If HTTPS is used to connect to an STMP serve is that the same as using S/MIME?
No. TLS encrypts the communication channel. S/MIME encrypts the message. I.e., it's the difference between "talking openly on a secure line" and "talking in code on an insecure line."
HTTPS is used to connect to an STMP
There seems to be a misunderstanding regarding what HTTPS and SMTP are. HTTP and SMTP are two distinct protocols. HTTPS is essentially HTTP over SSL/TLS, which secures the communication between the client and the server. Similarly, communications between an SMTP client and an SMTP server can be secured using SSL/TLS (there are two variants: SMTP over SSL/TLS directly, on a specific port, or TLS initiated via STARTTLS within the SMTP protocol; either way, HTTPS isn't used to connect to an SMTP server). In both cases, this is transport-level security.
In contrast, S/MIME is about message-level security, where the messages are encrypted (even when they've been received and are sitting in your inbox).
What can be relevant to both SSL/TLS (for HTTP, SMTP, ...) and S/MIME is the notion of certificates and PKI (Public Key Infrastructure), which is what helps make decision regarding the trust in the remote party, necessary for security.