Safari 7 and https / http, encrypted or not?

Question

Level 1

5 points

Safari 7 and https / http, encrypted or not?

Most pages in https will open in https (with the lock) at the first attempt.

But when I enter a certain URL starting with https:// or click the bookmark with https://… the resulting page will open in http (no lock) without any warning.

However when I then “reload” (the arrow at right hand side) the very same URL / page often will come up as https (with the lock).

I don’t know if Safari is “hiding the fact” that it’s https or if it’s not “secure” although I was asking for https to enter my login?

A good URL to test with is https://www.gmx.com (a webmail’s start page).

Both, Safari 5.1.10 and Firefox 26 will open that page in https at the first attempt.

Any ideas how to make sure it’s https when I’ve asked for https?

BTW: It doesn’t depend on extensions or JavaScript settings.

See also:

https://discussions.apple.com/thread/5770168?answerId=24459932022#24459932022

iMac, OS X Mavericks (10.9.1), FusionDrive

Posted on Jan 12, 2014 12:25 PM

Reply

Answer 1

sancho_p Author

Level 1

5 points

Jan 17, 2014 4:42 PM in response to sancho_p

Um, no one?

Digging deeper the “hides the lock / https connection” is in the boat again.

The lock will only be shown “if all parts of the page are in https”, but in my example they are not, there are some fonts linked in standard http.

OK, the very first time the URL has no lock but basically connects in https to the target site (this supports the “hiding” theory).

Strange that there is no visible warning, at least something like green and grey lock.

But why will the lock show up at the same page after reloading? The very same http “.woff” files are linked and show the same warning in the Error Console.

Is it because the fonts are cached already (but the source is still “insecure” ! )?

Is it a bug in Safari?

How to report that, if?

This posting may be related, too: https://discussions.apple.com/thread/5208777?answerId=22771983022#22771983022

Reply

Answer 2

Jan 22, 2014 10:39 AM in response to sancho_p

That's not a bug.

A second load of the page *is* secure, as no conection is made to an insecure site.

If you clear the error console before re-loading the page, you'll see no warnings, as there are none.

Reply

Answer 3

Jan 22, 2014 10:41 AM in response to BenJamieson

The 'bug' is with the website, and caused purely by sloppy web developers. They should know better than to mix secure and insecure content on a page and expect it to be labelled as secure.

Pretty basic stuff for a competent dev.

Reply

Answer 4

sancho_p Author

Level 1

5 points

Jan 22, 2014 1:53 PM in response to BenJamieson

Hi Ben, thanks for replying.

Your points do not convince me, however.

What you say would basically mean:

- The bug is in Safari 5.1.10 which will show https immediately?

- (I hesitate to look out of the Apple window …) The bug is in Firefox 26, too?

(FF gives a nearly invisible hint regarding blocked content at the connection)

- The site is secure only when loaded twice?

I know about cached images, but they are “loaded” anyway in that browser tab.

Is it more “secure” when the content is loaded from cache?

I’m with you when you say that others should do their job - but it isn’t.

I think the browser’s duty is to connect, inspect and protect me. If a requested image or font isn’t secure for the browser engine then the browser shouldn’t load it and inform me about.

When the message is “part of the requested page are not loaded” that’s sad but fine.

I want to know if my connection to the target server is secure, protected against eavesdropping.

That said, I was wrong - your arguments convinced me:

What Safari 5.1.10 does is hiding the head in the sand.

What Firefox does is straight forward.

What Safari 7.0.1 does is still incorrect and will drive many users towards FF / Chrome,

as they want to see the lock ...

(“Safari can not, isn't secure, my requested site was and is OK”).

There should be a secure and user-friendly solution (and from Apple).

I’ll drop them a line.

Reply

Answer 5

sancho_p Author

Level 1

5 points

Jan 22, 2014 3:14 PM in response to sancho_p

See also: https://discussions.apple.com/thread/5208777?answerId=22627102022#22627102022

There is a good example for a site “never showing a lock”,

even after reload,

but the requested page being in https:

https://www.thecpapshop.com

The Console says repeatedly:

“The page at https://www… displayed insecure content from http://www…”

The insecure content is png and jpg, it seems Safari doesn’t cache it.

And to me (dummy) it seems Safari can’t securely display a jpg.

Reply

Answer 6

Jan 22, 2014 4:40 PM in response to sancho_p

Not sure how hard this is to understand.....

If a domain has an SSL ceritficate, and serves content only from the secured domain, then the lock will display.

If a site has an SSL certificate and includes content form other random domains that are not secure, Safari, rightly, will not display the lock icon.

This is not new.

This is not abnormal

This is not a bug.

It is merely Safari not claiming a site is secure if it displays content from insecure sources - it makes no difference what that content is..... it's not secure. (after all, it's trivial to server a malicious script as a 'jpeg')

Period.

Safari is doing it's job by letting you know explicitly and clearly that the site you're on isn't secure. Its not wasting your time by telling you "well, some of this may be ok, but other bits aren't, so you decide what you do next" - it's doing the sensible, and pretty obvious, thing of saying "this isn't secure".

That's a good thing.

Reply

Answer 7

Jan 22, 2014 4:39 PM in response to sancho_p

Oh, and your link in this post is to a discussion that links to a site that is also to a site that mixes secure and insecure content, resulting in Safari behaving in exactly the way it's meant to.

Reply

Answer 8

Jan 22, 2014 4:54 PM in response to sancho_p

Regarding thecpapshop.com, they have explicitly set there server to serve pages and images with the 'no-cache' directive in Apache.

See: http://web-sniffer.net/?url=https://www.thecpapshop.com

This means (non-buggy) browsers will not cache the images.

This means reloading the page will require the (non-buggy) browser to reload the images.

This means the images will be requested from an insecure source.

This mans, naturally, the page is insecure.

Safari (non-buggy) does not indicate a secure page because it is not serviing a secure page.

Reply

Answer 9

Jan 22, 2014 4:59 PM in response to sancho_p

Safari 5.1.8 does not display a lock icon (correctly)

Maybe there was a bug in Safari 5.1.10, but versions before and after - not an issue.

Screencap attached.

Reply

Answer 10

sancho_p Author

Level 1

5 points

Jan 23, 2014 5:14 PM in response to BenJamieson

OK, this wasn’t a bug in 5.1.10 only:

As your example image (using Safari 5.1.8) proves,

Safari was clearly telling the user in the address line:

“https:// connection successfully established to www.requested.site”

Not an issue.

There was no doubt being https, no “bad_developer_at_target_site” - hint.

There was no lock icon in the good old days, it was either https or there was a WARNING:

“Safari can’t open the page … because Safari can’t establish a secure connection to the server …”

Apple. Straight forward. I love it.

***

Your ‘no-cache’ point is valid (thanks for the web-sniffer link, very useful).

However, a non-buggy browser will access the target site using https://

and inform the user to have done as requested (= confirm “https”).

Such a browser must not load the “insecure http-image” from other sources

if it can’t sandbox it and if there is danger that the image could gain access to communication data, user’s system, HD or whatever through that image.

An icon (?) for “Sorry, didn’t load some insecure content” would be appreciated.

As we both agree that mixed content should be avoided at the source we will never agree how a browser should handle the reality.

I think we've had our arguments 😉

Reply