Let's say a user is authenticated, and the entire account authentication process happened under secure HTTPS.
Upon successful login, the user is redirected back to the homepage. However, the homepage contains links within the website which do not have SSL enabled - basic HTTP.
For example:
http://example.com/foobar (no SSL)
Is this a security vulnerability, and if so, what severity? If not, why? Aren't the cookies unsafe when going from HTTPS to HTTP?
In terms of browsing security/privacy, any time you are over http, your traffic could be (and often is, see cache discussion below) intercepted and fiddled with by servers along the way. Period. You can't be sure if the page you see over an http connection is in fact the page that the webserver sent in response to your web client's request.
As far as session hijacking, the answer is a bit more complicated. The concern would be that you type your username and password over an https connection, and the server then sets a cookie on your browser that identifies you. That cookie will be sent back to the server by your browser with each subsequent request for pages, and the server will thus know that it is you asking for the pages. The concern is that somebody along the way was listening and copied that cookie. They could then send requests to the same website using your cookie, and the site would think it was you.
The Set-Cookie header has a secure flag (see here) which can be turned on when the cookie is originally given to your browser. If this flag is set, the web client will not send the cookie back to the originating domain except over an https connection.
It would be possible for a site to, say, have two authentication cookies, one of which is marked secure. That way, anytime you want to do something really sensitive you are required to have the secure cookie, and are thus redirected to an https page.
In that case, the site designers have to make a per-page decision as to what is "really sensitive" and what is not. The scope for "oops" is enormous. This is one reason why https all the way is preferred. There are reasons why this is not done by all sites:
(Probably the biggest reason): Many networks (your ISP potentially) maintain a cache server that watches traffic leaving their network. If it sees that you are trying to retrieve content (all the little pictures & icons on a popular page for example) that other people have recently retrieved, it will give you a cached version. There is all kinds of support for this: the original site has a way to indicate what can and cannot be cached, and for how long. All this is good for the ISP and the original site, since it means that they both have less bandwith crossing into/out of their networks. Https breaks this, as the proxy now has no idea what you are asking the original site for.
(no longer a problem) There is computational overhead to setting up a secure connection to a site for the first time. This used to be a problem for a server accepting lots https connections. This problem is largely gone now - there are several mitigating protocol factors, as well as acceleration hardware and other methods that have basically fixed this problem. I only mention this in case you hear that https puts a heavy computational load on the server: AFAIK that is no longer true.
Yes, however, this is a common pattern.
For example, this is how reddit's authentication works and Instagram's.
Frankly, the only thing it protects against is sending your password over the network in plaintext. But the process does expose your session and all of your browsing data over HTTP, which just means your session has the same strength as HTTP.
A few other takeaways from this.
