Google Security Warning

EverythingEverywhere

I got this message from Google today:

**Chrome will show security warnings on http://travelphotos.everything-everywhere.com

To owner of http://travelphotos.everything-everywhere.com,

Starting October 2017, Chrome (version 62) will show a “NOT SECURE” warning when users enter text in a form on an HTTP page, and for all HTTP pages in Incognito mode.**

All Smugmug accounts with custom domains are now going to generate security warnings in Chrome because they don't have SSL.

kygarden

I got this too. So...what are we to do?

EverythingEverywhere

Until they support SSL.......nothing.

Chasing Daylight

SSL is supported on SmugMug domains, which includes essential areas such as the shopping cart and account settings even when using a custom domain. If you have customers question the security of your site, confirm for them the areas where they will input information (such as the cart) are secure with SSL on the SmugMug domain. On the User Voice forum, it's been noted as being planned for the future http://feedback.smugmug.com/forums/17723-smugmug/suggestions/6498302-support-encrypted-connections-https-with-custom

leftquark

We’ve wanted to do this for quite some time now, but until recently it wasn’t possible to do it in a way that didn’t require some hefty work on all of your ends. Now that the technology is finally available to allow us to deliver a great experience and do it for you, we’ll be getting started on making this happen in the future. I'll continue to update the thread on the feedback forums with any updates.

leftquark

I also wanted to mention that your custom domains will NOT be marked as insecure unless the visitors is:
1) Browsing incognito, or
2) entering data into an insecure form

We've transitioned all password and credit card forms over to using https via secure.smgumug.com. Until we're able to release SSL for custom domains, your visitors will only receive a "not secure" warning when performing a search or filling out the Contact Form. I don't believe we use insecure forms in any other places. Normal browsing of your site will not trigger the "not secure" message.

SSL for Custom Domains continues to be one of our top priorities and, as mentioned, I'll update you as things progress.

denisegoldberg

@leftquark said:
I also wanted to mention that your custom domains will NOT be marked as insecure unless the visitors is:
1) Browsing incognito, or
2) entering data into an insecure form

I am seeing a "not secure" info message when browsing my site via custom domain. This is in normal mode, not incognito. There are no forms on the page.

Chrome:

Firefox:

leftquark

The changes Google is making in October are around the "i" info button in front of the URL:

denisegoldberg

@leftquark said:
The changes Google is making in October are around the "i" info button...

Thanks for the clarification. I think that implies that the "not secure" designation will then be shown in the address bar for the cases you outlined above. Is that correct?

leftquark

Correct -- it looks like the "Not Secure" will only show up if you're browsing incognito, or if you're filling out a form. If you're normally browsing and not filling out a form, then only the "i" will show up (no "i not secure")

BigRed

@leftquark said:
I also wanted to mention that your custom domains will NOT be marked as insecure unless the visitors is:
1) Browsing incognito, or
2) entering data into an insecure form

We've transitioned all password and credit card forms over to using https via secure.smgumug.com. Until we're able to release SSL for custom domains, your visitors will only receive a "not secure" warning when performing a search or filling out the Contact Form. I don't believe we use insecure forms in any other places. Normal browsing of your site will not trigger the "not secure" message.

SSL for Custom Domains continues to be one of our top priorities and, as mentioned, I'll update you as things progress.

Apparently, Password entry "forms" are also impacted, at least in Firefox 57.0. I'm seeing this scary message popup:
"This connection is not secure. Logins entered here could be compromised. Learn more."
Example password-protected folder: http://www.janicebrowne.com/Photo-Galleries/Family-Albums

leftquark

Yea, firefox has been doing that on passworded galleries.

I hope to have an update on SSL for custom domains very soon, which will solve all of this

BigRed

@leftquark said:
I hope to have an update on SSL for custom domains very soon, which will solve all of this

Any news on this? I have a new site ready to rollout, but can't point to its custom domain until this gets fixed.

leftquark

At this point I can say that it's in work, and i'll have an update next week regarding the timing. Stay tuned soon!

leftquark

SSL for Custom Domains will launch on January 17th and everyone with a custom domain on SmugMug will be moved to https with a secure certificate over a 7 day period. Your sites should be secured with SSL by January 25th or sooner and you will not need to take any action to enable this, as long as your custom domain is properly configured per our help pages. All links on your SM website will convert to https automatically and any links you’ve shared without https will redirect to https.

For those of you that enabled SSL on your custom domains via the various “hacks”, you’ll be receiving several emails from us, indicating that you’ll need to remove these when we push SSL live on January 17th or you will risk your site being inaccessible via your custom domain (you’ll want to do it on January 17th to minimize risk of links or your site not working. If you do it before Jan 17th, links you’ve shared with https wil no longer work).

Shinrya

Legend!

Thanks for the update.

Lille Ulven

Perfect, thanks @leftquark & the smugmug team!

Ferguson

I love late arriving Christmas presents. Thanks! Good luck.

leftquark

Just 2 quick notes:
1) Enabling SSL for custom domains will break peoples sites that had enabled the "hack" for https prior to our release. Anyone who has implemented this will need to undo it when we go live on January 17th.

2) Because we didn't want to break the custom domains for the people who had forced https prior, we were unable to completely test everything around SSL for Custom Domains. As such, beginning on January 17th we'll be generating SSL certificates for each of your domains, and they'll be renewed and remain active as long as you tie your custom domain to SmugMug in your SM Account Settings. However, we will not initially redirect non-SSL (http) traffic to https at this time. Links generated in your breadcrumbs, Folder/Galley and Menu Content Blocks will continue to use non-SSL (http) links. Once we're able to verify everything with the SSL certificates looks good, we'll begin moving all links to https, and then lastly automatically redirect http traffic to https.

This means that, on January 25th, someone typing in "http://www.yourdomain.com" will not be moved to "https://www.yourdomain.com". However, if they do type in "https://www.yourdomain.com" they will land on a secure site.

Allen

I would think all the links on a site would be relative so wouldn't however the site was entered hold?
Would adding the "s" when entering work?
Edit: think I see your answer in your last sentence.

Ferguson

@Allen said:
I would link all the links on a site would be relative so wouldn't however the site was entered hold?
Would adding the "s" when entering work?

Unfortunately they are not, I found that (I'm going from memory not looking at the moment) the dropdown menus are absolute not relative if you use the wizard to chose a gallery as opposed to manual entry of the link. It sounds like they don't plan to change those.

I THINK that means if I start on an https link to my site, and use a menu to navigate (and haven't manually adjusted), at least initially I will shift back to http.

This has actually proven a problem and I keep meaning to go through and fix all mine -- if you try running in your nickname.smugmug.com domain instead of custom, it shifts you immediately back to custom (or conversely to nickname I presume if you created them there? Not sure).

Maybe, while you're fixing these links for us, you could shift to relative? Is there some reason they are absolute to begin with?

Allen

All my created drop menus use pure relative links
Same with all html or any other links I've added, all relative.

Except for the "home" link. Anyone know how to enter a relative home link, if possible?

Ferguson

@Allen said:
All my created drop menus use pure relative links
Same with all html or any other links I've added, all relative.

But you must have done that manually?

Below's an example of a "normal" link for me, where I just followed the wizard to pick the destination. You can test it out, try going to LinwoodFerguson.smugmug.com, and use the top menu Sports/Events, Medieval Faires. You'll see it switch to my custom domain.

Here's one I did manually (menu, Sports/Events, FGCU, General) and it doesn't switch:

I keep meaning to go through and convert them all, just haven't. But I have always wondered why they are hard coded internally as absolute by smugmug, I would think relative was always better.

Allen

I've created all links (custom url) but the home link manually from day one of "NewSmug". Every piece of html only have relative links. So I should not have to do any converting.

Ferguson

@Allen said:
I've created all links (custom url) but the home link manually from day one of "NewSmug". Every piece of html only have relative links. So I should not have to do any converting.

I never realized that SM's tools were building absolute links until I was done, or I would have. Now I'm lazy. And puzzled why they do.

leftquark

I'll try to update some of the other threads as well but ... we've begun issuing SSL certificates for customers with Custom Domains. We hope to have generated certs for all custom domains within a week. You can see it on my site, for example: https://www.aaronmphotography.com/

EverythingEverywhere

I tested my subdomain with https and it seems to work. However, if I type in the subdomain without any protocol, it doesn't default to https yet. Will there be a redirect to the https version of the page?

leftquark

@EverythingEverywhere said:
I tested my subdomain with https and it seems to work. However, if I type in the subdomain without any protocol, it doesn't default to https yet. Will there be a redirect to the https version of the page?

Yep - (I mentioned in a comment above, but it got buried, that) we wanted to make sure everything worked on https before forcing/redirecting all your traffic to it. Once all the domains have SSL certs (about 7 days from now), we'll give it another week or two and then start the process of redirecting. It'll most likely be a 2 step process:
1) If the visitor enters on http, we'll update all the links on your page to use https, so that their second page view moves to https. Once we're confident everything looks good there we will...
2) Redirect all http to https

Ferguson

@leftquark said:
1) If the visitor enters on http, we'll update all the links on your page to use https, so that their second page view moves to https. Once we're confident everything looks good there we will...

But only links to Smugmug or the custom domain?

I presume regular, non-image tags won't be changed otherwise?

I do not THINK I have any, but what happens if one has image tag links which are not https (i.e. from a site that doesn't support it), it's kind of a darned if you do, darned if you don't situation?

Did you see the comments on menu links above that are absolute? Any chance as you are doing all this magic you will just roll absolute links (to smugmug to the same customer domain or nickname) into relative links?

(Postscript: the initial version of this quoted the wrong line, the redirects were not my concern but the dynamic link switches)

In the long run none of us want the extra cost of redirects, so the real question is what should users do -- manually change everything to relative (where it applies) or are you going to do it for us as part of the updates?

Tom Foster

@leftquark said:
Yep - (I mentioned in a comment above, but it got buried, that) we wanted to make sure everything worked on https before forcing/redirecting all your traffic to it. Once all the domains have SSL certs (about 7 days from now), we'll give it another week or two and then start the process of redirecting. It'll most likely be a 2 step process:
1) If the visitor enters on http, we'll update all the links on your page to use https, so that their second page view moves to https. Once we're confident everything looks good there we will...
2) Redirect all http to https

Hi Aaron, I was just wondering as to those who have Smugmug running on a subdomain. My Smugmug page is at http://gallery.edinburghphotography.com

If I enter https://gallery.edinburghphotography.com it works but if I put https://WWW.gallery.edinburghphotography.com it doesn't (leads to the security error). I presume it's because 'www.' is effectively a subdomain of a subdomain and the SSL certificate is only for first-level subdomains. Now this isn't necessarily a problem but when the redirect to https occurs can it be ensured that it is redirected to the site without the 'www'?

Thanks for all your work on this as can appreciate it's a bit of a tricky thing to implement across so many domains!

Ferguson

Mine changed and I have been experimenting a bit.

It's mostly working, but I am finding two problems that provide inconsistent results, one my fault completely (but others may have so mentioning it), and one that I still find irritating that is SM's issue, but I am going to just fix it.

The first is that if you have HTML which has A records which are explicit with HTTP, they will not change, and you can flip back to HTTP from HTTPS. E.g. my logo at the top explicitly had an A tag for my site's homepage, and every time I clicked it, I was back in HTTP. Change to relative, everything works.

The second is more subtle, and arguably does not matter, but might for some -- the site will not run consistently in both nickname and custom domain due primarily (but I expect not exclusively) to menu links. SM is changing http to https as needed, but only for the current (or maybe custom, not sure) domain, so when attempting to run as a nickname, things do not work, you flip back to to the custom domain (or maybe nickname if doing the reverse) and perhaps also change protocol.

The answer to all this is go manually though and use relative links in a custom URL, instead of using "page I choose". Which is a pain. I really don't understand why Smugmug is hard coding in the domain in those, instead of using relative links. But it was past time for me to fix them.

But the good news, except for some scary chrome warnings (I started a new topic), it seems to work quite nicely so far.