When sending data from a server / device through HTTP, to a destination that is enforced by https, is that data encrypted in transit?
HTTP -> HTTPS
Or does the source and the destination both have to enforce HTTPS?
A protocol is the language between a client and the server. This language might have features including ones related to security. HTTP is basically for browsers requesting web resources from web servers without any encryption, authentication or integrity protection. HTTPS is the same, but one that provides these features (HTTPS is actually HTTP, protected by TLS).
Each tcp connection between components uses one protocol (it's sometimes a little more difficult than that, but let's stick with this, it's good enough for now). In case of web components, it's typically either http or https. Each resource that is downloaded (a page, an image, a javascript file, any resource) is typically downloaded in its own separate connection. Whether that will be http or https depends on how the page references it.
So in practice, if you have a look at a html page that you downloaded over http, it can still reference resources with https urls, in which case those will be downloaded by your browser via https. It can also happen the other way round, a page downloaded over https can reference resources over plain http, but your browser will then warn you.
In short, your question doesn't make sense because you don't "send data through http, to a https destination". If the destination is https, the connection will be using https. In a web application, the page itself can be downloaded via http (in which case the html code and any data embedded in the html itself will not be protected against man-in-the-middle attackers), but it can reference further resources, images, css, javascripts via https, which your browser will then download securely.
Related
I understand that HTTP is a protocol that allows information to be transferred between a client and a server. At the moment, this protocol is used everywhere: when we're opening needed web page, downloading music, videos, applications...
MDN
HTTP is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance, text, layout description, images, videos, scripts, and more.
But it's not entirely clear to me what exactly HTTP does during this information transfer. If, as I read, a protocol is essentially a set of rules, then does it mean that HTTP just setting up rules for passing information between server and client? If so, what are these rules and what are they for?
Hypertext Transfer Protocol is a communications protocol. It is used to send and receive webpages and files on the internet. It is now coordinated by the W3C. HTTP version 1.1 is the most common used.
HTTP works by using a user agent to connect to a server. The user agent could be a web browser or spider. The server must be located using a URL or URI. This always contains http:// at the start. It normally connects to port 80 on a computer.
A more secure version of HTTP is called HTTPS (Hypertext Transfer Protocol Secure). This contains https:// at the beginning of the URL. It encrypts all the information that is sent and received. This can stop malicious users such as hackers from stealing the information and is often used on payment websites. HTTPS uses port 443 for communication instead of port 80.
with TLS 1.3 already in place, and around 94% of the browsers compatible with 1.2 (https://caniuse.com/#feat=tls1-2)
with certificates wittily available or even free
with amp even requesting https
What is left for http?
does it have any sense to spend a minute on developing under port 80 aside of a redirect?
please, do not vote negatively, this is a open question to the community, trying to figure out any real use-case for the http protocol
Static content, or content that we don't care it to be "stealed" or "trafficked", don't need HTTPS and still could use HTTP.
For example, you might not need HTTPS for the jquery.js script resource (or for some static logo image), at least in some trusted corporate Intranet. And HTTP needs less resources (both on server and on client side) than HTTPS (because no encryption occurs).
Also, in some cases, both the HTTP server and the HTTP client (the browser) is on the same local secured network, or even both running on localhost (perhaps your Linux laptop without network connection). Then you don't need HTTPS.
And server side HTTP libraries (like libonion) are slightly more complex to use with HTTPS than with HTTP.
Is there any possibility to send HTTP headers on an ftp:// URL? How would I go about it?
What I want is HTTP based crawlers to see an HTML Response (in the headers) while human users see the pure FTP Content.
What would be the smartest way of solving this problem? I thought about user agent specific redirection, however this seems to be against most search engine's guidelines.
What I want is for bots to index an HTTP version of the content, while normal users can get access to the FTP version, all while using a single ftp:// URL.
Is this doable?
It's NOT doable.
You cannot redirect ftp:// URL to http:// URL. The FTP protocol has no redirects. FTP protocol does not even know what URL is. Nor does a web browser (acting as an FTP client) send "user agent" or anything similar to the FTP server.
There are also no headers in FTP protocol (but that's just a technicality, comparing to the fact above).
FTP protocol is completely different to HTTP.
You are obviously confused by the web browsers (all of them) presenting an FTP resource the same way as an HTTP resource. But it's just a "game" by the browsers. They are nowhere near similar.
Note that FTP was invented eons before Internet, HTTP, web and URLs.
Though note that you may be able to do it the other way around. You should be able to redirect HTTP to FTP.
But I still do not think it's a good idea. If the clients need FTP, they probably want to use a real FTP client, not a web browser. And a real FTP client won't understand HTTP (redirects).
But this question is kind of meaningless, now that all major web browsers are gradually removing a support for FTP anyway.
Wikipedia defines HTTP(S) or S-HTTP as a security layer over HTTP:
Technically, it is not a protocol in and of itself; rather, it is the
result of simply layering the Hypertext Transfer Protocol (HTTP) on
top of the SSL/TLS protocol, thus adding the security capabilities of
SSL/TLS to standard HTTP communications.
Logically, it implies that every feature and aspect of HTTP (e.g. methods and status codes) exists in HTTPS.
Should I expect any caveats or differences when switching an existing HTTP REST interface to HTTPS?
There doesn't seem to be any limitation of what you can do with HTTP but not HTTPS. The only limitations/differences relate to the fact that the connection is encrypted. As Eugene mentioned, this includes the fact that HTTPS cannot be proxy-cached. There are however some caveats:
HTTP inline content inside HTTPS page
If you start using HTTPS for sites where you originally used HTTP, problems might arise with HTTP inline content, e.g. if you use 3rd party HTTP services or cross-domain content:
scripts: google maps API
iframes: other webs, facebook, google ads, ...
images, static google maps, ...
In that case, many browsers will disable the "insecure" HTTP content inside HTTPS page! For the user, it is very hard to switch this off (especially in Firefox).
The only reliable way around that is to use protocol-relative URLs. So, instead of:
<script src="http://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false"></script>
which would break on HTTPS page, you will just use
<script src="//maps.googleapis.com/maps/api/js?v=3.exp&sensor=false"></script>
which will work as HTTP on HTTP page and as HTTPS on HTTPS page. This fixes the problem.
The downside of course is that it is useless encryption of large amount of network traffic, that is not vulnerable and wouldn't normally have to be encrypted. This is the cost of the paranoid browser approach to security (like year ago, there was no warning from FF in this situation, and I was completely happy. World changes ...)
If you don't have signed SSL certificate for your domain
Another caveat of course is that if you don't have SSL certificate for your domain which is signed by trusted CA authority, then if your users will use HTTPS, they will have to pass a terrible scary 4-5 step procedure to accept the certificate. It is almost impossible and unprofessional to expose an average user (unaware of the problematics) to this. You will have to buy certificate in this case. Many times you end up using HTTP instead of HTTPS because of this. So if you cannot afford to buy the certificate, the browser paranoia forces you many times to use insecure HTTP protocol instead of HTTPS. Again, 6-7 years ago, it wasn't the case.
Mixing HTTP and HTTPS - cookie and authorization problems
If you use both HTTP and HTTPS within the same session, you might run into problems because sometimes they will be treated as separate sites (even if the rest of the URL is the same). This might be the case of cookies - in some cases they will not be shared between HTTP and HTTPS. Also, the HTTP authentication - RFC2617 will not be shared between HTTP and HTTPS. However, this type of authentication is now very rare on the Web, possibly due to lack of customization of the login form.
So, if you start using HTTPS, easiest way is then to use HTTPS only.
After several years of running HTTP over HTTPS, I am not aware of any other caveats.
Performance Considerations
HTTP vs HTTPS performance
HTTPS vs HTTP speed comparison
HTTPS Client/Broswer Caching
Top 7 Myths about HTTPS - Note commentary on HTTPS caching that is handled differently in browsers. It's from 2011 though, the browsers might have changed.
Will web browsers cache content over https
More on why there is no HTTPS proxy caching
Can a proxy server cache SSL GETs? If not, would response body encryption suffice?
UPGRADE command in Websockets via HTTPS
While the WebSocket protocol itself is unaware of proxy servers and firewalls, it features an HTTP-compatible handshake so that HTTP servers can share their default HTTP and HTTPS ports (80 and 443) with a WebSocket gateway or server. The WebSocket protocol defines a ws:// and wss:// prefix to indicate a WebSocket and a WebSocket Secure connection, respectively. Both schemes use an HTTP upgrade mechanism to upgrade to the WebSocket protocol.
http://en.wikipedia.org/wiki/WebSocket
As a coder of REST, I do not see any possible caveats when you switch HTTP REST to HTTPS. In times if you find some, you would definitely have them in normal HTTP REST too.
I've got an internal web application that's designed to work in concert with a server running locally on the client machine. (For the curious: the local server is used to decrypt data retrieved from the server using the client machine's GPG key.)
The internal web app is served over HTTPS while the local app is accessible via localhost. It used to be that I could make unencrypted AJAX requests from the page to localhost without any issues; but it seems that recently Chrome was updated to disallow HTTP requests to any destination from pages served over HTTPS.
I understand that in the vast majority of cases, HTTP requests from a page served via HTTPS constitute a security hole. However, since I have complete control over the endpoint in this case (i.e., localhost), it seems to me that it should still be perfectly safe to make HTTP requests to that one destination even when the host page has been served via HTTPS.
Is this possible? To whitelist localhost somehow?
Since you are in control of both the client and the server, it sounds like a good candidate for Cross-Origin Resource Sharing (CORS). The server will have to set a few response headers to give access to the client. You can learn more here: http://www.html5rocks.com/en/tutorials/cors/