Safari Tests 'Not Secure' Warning For Unencrypted Websites (cnet.com) 66
Similar to Chrome, Apple's Safari browser is testing a warning system for when users visit websites that aren't protected by HTTPS encryption. "The feature for now is only in Safari Technology Preview 70, a version of the web browser Apple uses to test technology it typically brings to the ordinary version of Safari," reports CNET. From the report: Apple didn't immediately respond to a request for comment on its plans for bringing the warning to mainstream Safari. Apple's browser does warn you already if you have an insecure connection to a very sensitive website for typing in passwords or credit card numbers.
Re: (Score:3)
Do we really need SSL on everything?
The reality is that you need SSL just to prevent content from being transparently altered en-route; it is not only for secret content, but just for knowing what the content actually was!
Sad, but true.
Re: (Score:1)
Google needs SSL, because they control the endpoints, and don't need any of 'their' info leaking out to anybody else.
Apple is kinda keen on that, too. Not as ravenous as Google with people in general, but they have a strong herding instinct for their
'sheep.'
Re: (Score:2)
So you believe Apple joining on the SSL everywhere bandwagon is because... they're actively working against privacy?
Re: (Score:1)
So you believe that Apple doesn't monitor your connection to the endpoints they control?
Re:Isn't this a waste? (Score:4, Interesting)
So what you’re saying is that we need content validation without full encryption for most things. This is how windows update (and I think apple update). Hashes of the packages are transferred securely, while the bulk data is in the clear. This allows the data to be verified, while still permitting caching to work.
Re: (Score:2)
Nope. More standards is not what we need.
The problem is already solved, by existing deployed layers.
Transparent caching by third parties is a happy idea with flowers and chirping birds, but in practice you gotta wear a condom, er, something something TLS.
Re: (Score:2)
How easy to add exception on non-PC clients? (Score:2)
I was about to complain about local devices, like my NAS, before I discovered that I can set up a self-signed cert for its local domain in a few clicks.
How easy is it to add an exception on your mobile and set-top devices in order to use a self-signed certificate? I seem to remember reading that some game consoles and streaming boxes didn't allow clicking through the unknown issuer exception interstitial.
Re: (Score:1)
This ^
Re: (Score:2)
Signing != encrypting! Granted, SSL might make it harder to alter content but it is weak compared to signing the content.
What you are saying is like saying that since you downloaded a piece of software through SSL, you are safe enough and you don't need to check the signature.
Note that signing doesn't require encryption at all.
Some corporate environments and maybe even some countries could force you to have their certs trusted. They can then alter content at will.
So in the end, you do not need encryption at
The server signs every packet it sends (Score:2)
What you are saying is like saying that since you downloaded a piece of software through SSL, you are safe enough and you don't need to check the signature.
Every connection you make to a TLS server is signed by that server. Are you assuming an attack model that involves tampering with the downloadable software before it even reaches the server?
Furthermore, encryption is a weak way to guarantee that content hasn't been altered compared to signing.
A form of signing is implicit in TLS, as it uses a message authentication code (MAC) to detect tampering with a packet's ciphertext. Older cipher suites in TLS separate the MAC and encryption into two steps; newer ones use authenticated encryption with associated data (AEAD), which bakes MAC into the cipher's mode.
Re: (Score:2, Insightful)
Do we really need SSL on everything?
Yes. Only securing "sensitive" traffic makes it trivially easy to identify "sensitive" traffic.
Also, Yes! What what you consider non-sensitive information may, in fact, be useful to a malicious actor listening in on the wire.
Do you really want your ISP any one else in the transit path between you and Google knowing what search terms you enter? That's between you and Google. Do you want your ISP censoring your Internet? Modifying pages as they come back to remove "bad" words?
SSL also helps to prevent modific
Why not signing-only? (Score:2)
SSL also helps to prevent modification of data in transit.
So would a signing-only cipher suite. Signing-only would also have the advantage, as Strider- points out [slashdot.org], of allowing an ISP to run a caching proxy for its subscribers to use.
Replay-resistant index, replayable data (Score:2)
How do you make sure a malicious actor will not serve the old content on purpose
If you're using a signing-only scheme for long-lived bulk data, each version has a different URL. Then the index file, which was transmitted separately using a replay-resistant scheme, indicates that a different URL is the newest version of the file.
Re: (Score:2)
Shared server hosting (Score:2)
Server Name Indication (Score:2)
Have they fixed this problem? As I recall, the httpd would have to furnish the certificate before the client even sent the Host header.
That's why the client sends the hostname in cleartext as part of the ClientHello message when it opens a connection. Firefox, Edge, Chrome, and Safari all send Server Name Indication (SNI) [wikipedia.org] in the TLS handshake, as does Internet Explorer on all supported Windows operating systems. The last major web browsers not to support SNI were Internet Explorer on Windows XP (whose extended support ended four and a half years ago) and Android Browser on Android 2.x. Does your site get a lot of page views from those anci
Self Signed (Score:3)
False sense of security (Score:2)
I don't see why a self signed certificate gets a warning, but http doesn't it is no less secure.
A self-signed certificate gives a false sense of security, whereas the http: scheme gives a true sense of insecurity. A true sense is better than a false sense.
It is really annoying that you have to pay someone a recurring fee just to add a little security.
Every domain name registrant is entitled to a reasonable number of certificates [letsencrypt.org] from Let's Encrypt without charge. Or by "someone" do you refer to Gandi, Namecheap, Amazon Route 53, and other domain name registrars?
Re: (Score:2)
A self signed on an internal private network, is priestly safe and good form.
Provided all clients that will access the server, such as streaming boxes accessing your NAS, even allow use of self-signed certificates.
Re: (Score:2)
It is really annoying that you have to pay someone a recurring fee just to add a little security
You don't. Either get a free certificate, or add your own self-signed root certificate to the trusted store in all your devices and you won't get a warning again.
Certificates serve for more than encryption. They also serve for identification. This is precisely why self-signed certificates get a warning as it breaks one of the two fundamental points of security:
1. You know who you are talking to.
2. You know no one else is listening.
But in principle I agree, unencrypted information should be called out, but e
Re: (Score:2)
Let's Encrypt offers free certs. You can install your own trusted root cert on your own machines for stuff like routers.
Re: (Score:2)
MITM (Score:2)
It should also warn if it detects corp MITM with forged root CA and wildcard certs.
Next time try fixing some bugs (Score:2)
If you ever tried to get involved into the development process of webkit you will soon understand why Safari has become the worst browser around. I posted a couple of bug reports over the last few months and the reaction I got was zero, absolutely nothing. During the same period I wrote some bug re
Re: (Score:2)
It's all part of their plan to make the worst browser in the world. It's hard to do - Microsoft have had two goes at it, and have generally done pretty well. Apple are trying pretty hard with Safari, and all 8 of it's users are providing them valuable feedback. Meanwhile, Apple are adding naggons to OSX so that you can never quite be free of Safari - and never quite being free of the worst browser is indeed one of it's finest features (see: IE).
Fun anecdote: Yesterday, Firefox got its knickers in a twist, a
Re: (Score:2)
With QUIC on the way and HTTP3 on the horizon, we need an encryption scheme that is on be default on any web server and that does not require certificates - just the encryption.
Encryption without trust is not just meaningless doublespeak it's actually dangerous.
The public hears "encrypted" and thinks it means "secure".
Re: (Score:2)
Re: (Score:2)
When the public thinks "secure" they dont think the same thing that you do about what that means, so your point is less than nothing.
I disagree. Everyone knows what secure means. When someone buys something from an ecommerce site or logs into their bank account there is no confusion in anyone's mind as to what secure means in the context of what they are doing.
Re: (Score:2)
So again... you havent said shit... you havent made a point.. you are just waving your hands
Re: (Score:2)
And so long as you always get to cherry pick what conditions to frame the situation you put "everyone" in ... you might as well declare unencrypted HTTP hitler, because thats about as much honesty and sense you are making.
SSL was invented by Netscape specifically to address needs of ecommerce.
To this day one of the most common scenarios where general public cares most about security on the Internet has to do with monetary transactions conducted via Internet. For most this means buying shit from ecommerce sites and some form of online banking. It's in this context they are most exposed to and familiar with the concepts of security and encryption.
So again... you havent said shit... you havent made a point.. you are just waving your hands
I don't believe referencing common activity conducted by the general public whe
Re: (Score:2)
that "trust" requires an expensive cert and a third computer in the loop (the server which is inexplicable presumed to be trustworthy even thought there is no cert for it being verified by some other (fourth?) server, which would of course need a cert verified by some (fifth?) server, etc.
In fact, who said that this current scheme/scam provides ANY true confidence and security?
The old line "who died and made YOU king?" comes to mind.
What I actually said is encryption without trust is meaningless doublespeak. This is a basic fact of reality not open for debate any more than the outcome of 1 + 1 is open for debate.
The rest is you yourself attacking a strawman created exclusively from your own imagination insinuating things neither stated or implied. My response is exclusively in the context of "encryption" without "trust" advocated by OP.
Saying a specific source of trust is no good or other sources can be used instead is NOT the argume