Slashdot Mirror
Safari Tests 'Not Secure' Warning For Unencrypted Websites (cnet.com)
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.
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.
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 modification of data in transit. The most easy example of this is inserting malicious javascript in a page as it passes through one of the many hops enroute to you. With SSL you have some confidence (if you trust the CA, for example) that you are talking directly to the remote host you think you are and that nobody can insert malicious code or modify the data on its way to you without your client noticing.
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.'
I've pre-paid for a few years on a shared-hosting plan. Since I don't have a dedicated IP address, that means my little blog doesn't have an SSL certificate. I've got 2-factor authentication turned on, so I'm not super-worried about credentials being intercepted... is there anything else I really need to worry about?
Silicon & Charybdis McLuhan Kildall Papert Kay
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.
...si hoc legere nimium eruditionis habes...
So you believe Apple joining on the SSL everywhere bandwagon is because... they're actively working against privacy?
It's turtles all the way down.
I don't see why a self signed certificate gets a warning, but http doesn't it is no less secure. An Icon saying it is less secure should be enough (say you may not be going to the site you expect). It is really annoying that you have to pay someone a recurring fee just to add a little security. Even worse for routers that don't have a DNS entry, you have to start managing your own certificates.
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. Given how many people have the password to by wifi (pretty much anyone who ever visited the house), this is probably a good thing.
This ^
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.
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 all to make sure the content hasn't been altered. You only need signing. Furthermore, encryption is a weak way to guarantee that content hasn't been altered compared to signing.
See here if you weren't already aware of that fact:
https://users.ece.cmu.edu/~adr...
Everything I write is lies, read between the lines.
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, of allowing an ISP to run a caching proxy for its subscribers to use.
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) 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 ancient, unsupported browsers?
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 from Let's Encrypt without charge. Or by "someone" do you refer to Gandi, Namecheap, Amazon Route 53, and other domain name registrars?
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.
It should also warn if it detects corp MITM with forged root CA and wildcard certs.
I do not understand why Apple neglects Safari's development so much. It is years behind Chrome, and the only reason why it's market share is still that high is probably that iOS users simply have no alternative.
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 reports for Chromium and Firefox, and about half of the bugs were fixed, on the others there usually was a brief discussion. Screw webkit, I will no longer write bug reports because it obviously is just a waste of time.
Signature deleted by lameness filter.
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".
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.
+1 Well done sir.
"His name was James Damore."
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.
"His name was James Damore."
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.
NO HELL FUCKING NO. I should NEVER need a third party's permission to pop up a website. Fuck you and authoritarians like you. The web should always be able to transmit in the clear. Dont co-opt freedom for your illusion of safety.
Good-bye
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.
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.
So again... you havent said shit... you havent made a point.. you are just waving your hands
"His name was James Damore."
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 where security has the highest profile exposure in their lives is cherry picking.
So you believe that Apple doesn't monitor your connection to the endpoints they control?
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 argument of OP: "we need an encryption scheme that is on be default on any web server and that does not require certificates - just the encryption"
What's required is a new scheme that ditches all this fake confidence. The new scheme should allow users to "sneakernet" certs and keys too... so a private business concern or members of an extended family, for example, could exchange digital certs in-person or via snail mail (like on USB keys) which would then be used on each end of the digital communications without the use of some 3rd party server.
I've been advocating trust off-ramps by limiting scope of global trust anchors exclusively to role of initial service discovery for many many years.
I've advocated for adoption of specific readily available and accessible technological solutions (standalone secure authentication) denied from being rolled into browsers for purely selfish political reasons. More importantly I've implemented these solutions in the software I develop.