HTTPS and asset publisher

[sdj sdj，修改在14 年前。]

Hi,

I have a web server and tomcat with LR on it. There are public and protected sections of the website. The settings below are working OK to make sure that the credentials are protected during login form posting and subsequent browsing of the protected section of the site (done via https).

company.security.auth.requires.https=true
web.server.http.port=80
web.server.https.port=443
web.server.protocol=https

The problem is with the asset publisher embedded on the public pages. The URL's for the articles shown in the asset publisher are always using HTTPS even when I am not logged in, just browsing the public website using HTTP. It appears it is due to the web.server.protocol=https property that forces use of HTTPS in the asset publisher links regardless of whether the page is retrieved via HTTP or HTTPS.

Has anyone got any ideas how to fix this ?

BTW: If I switch this property to web.server.protocol=http LR behaves erratically. One can't login due to the cookie being lost somehow, but I would not be concerned about this if there is a fix for the set up above.

Thanks
SDJ

[Olaf Kock，修改在14 年前。]

Is there any hard requirement to not use https for non-logged-in access? I'd rather care for the opposite and accept more https than necessary. In fact, operating a mixed http/https scenario almost always leads to problems, as you see in your "BTW" mention. One of the problems is that - when you start in https - you most likely get a session cookie that's marked to be transmitted 'securely' only. Thus, once you fall back to http, even for only one single request, you're not transmitting the session cookie and get a new one - overwriting the previous one that contained your identity. Now you're logged out.

Do yourself a favor and use https only.

This might not be the answer you're looking for, but I've seen so many problems with mixed installations that are all solved with this pragmatic solution. IMHO the price of a bit more required computing power is marginal.

[sdj sdj，修改在14 年前。]

Hi Olaf,

Thanks for sharing your thoughts.

In fact there is practically no mixing of http/https environments.

1. Users who are visiting only public website always use HTTP and nothing else.

2. Users who are using protected (secure) website initially land on the website with HTTP but then they login and afterwards they use HTTPS. The form action of the login portlet is using HTTPS so even though the page was requested using HTTP the posting is via HTTPS and after this point the user stays on HTTPS, never going back to HTTP. So effectivelly no mixing happens.

Forcing HTTPS for public website just makes no sense. If I can make an analogy of HTTP being the police using regular uniforms and HTTPS being the police using kevlar vests. So forcing HTTPS, by the analogy would mean the police wearing kevlar vests 24x7 - when they do no risk duties, have meetings or go to lunch. Just makes no sense. It is expensive and makes everyting slow and the only explanation I can offer to those asking why is "The product I use is forcing me to do so".


Thanks
SDJ

[Olaf Kock，修改在14 年前。]

Hi,

I didn't mean to say that "the product forces you to do so". My comment is independent of product: It's so much more secure to not operate both. In fact, you've already mentioned one of the problems: When the login form is loaded through http, but submitted through https, any attacker might change the form target to another site (as it's not encrypted and authenticated), thus you already have created a security hole that wouldn't be there if you used https only. There are many more, most of them non-obvious but existent. And it's purely a function of implementation of the protocols, not of the underlying application. My recommendation is the same with any server environment - not only liferay.

Regarding your kevlar vest analogy, I'd like to contrast with the option to always wear bulletproof cotton if it was just 10% heavier than standard but otherwise identical (in comfort and appearance).

Cheers,
Olaf

[sdj sdj，修改在14 年前。]

Hi Olaf,

You are right about the page with form in it. It has to be served via HTTPS to avoid man in the middle attack.

I am not convinced about the public content going via HTTPS. Have you got any pointers on the web to substantiate the claim? If you do, could you please list them (I've done some googling without success).


...and if anyone else has any suggestions about the original question, how to do the LR configuration to avoid asset publisher and possibly other portlets using HTTPS in the links they produce while browsing the public pages unauthenticated, would be greatly appreciated.

Thanks
SDJ

[Olaf Kock，修改在14 年前。]

Sorry, I don't have any (citable) references at hand. I remember to have seen such an article way after I came to this conclusion myself - The number of potential errors Ive seen with mixed operation was strictly astonishing, especially when https was presented not as an option but as a requirement for certain operations.

If I happen to find the reference, I'll post it, but chances are I won't find it again.

Another aspect I remember is that you need to make sure to hand out new session cookies when you switch to https, otherwise the session id might have to be recorded prior to login and using it will get an attacker into a later authenticated session.

But as this still doesn't answer your original question, I'm staying quiet now...