Mozilla intends to deprecate HTTP-without-TLS
-
User avatars if we use them in definitions / quotes come to mind.
i has plan for that. ;-)
-
Well it's just a certificate. Your HTTP server flavor should be irrelevant. Unless they're doing something really strange...EDIT: Oh, so they are. Ignore that then...
-
That's more like they're planning to make themselves completely obsolete in the eyes of users.
This was my thought. When they deprecate it, presumably they'll start warning users about going to http sites. This will finally kill their browser.
-
Tell that to modern browsers. As in, set up a secure WebSocket server on a private network range using a self-signed certificate and connect to it from a browser using JS WebSocket API without manually importing the certificate. I'll wait
Dude, I can't even get chrome to accept a self signed cert for our testing environment (all in our private network). That's after downloading it and going through the import process. It just gives me some other bullshit error. JUST STOP FUCKING WARNING ME ABOUT THIS THING ALREADY.
-
Wait really? That must have changed, cause it was easy last time I did that... (~2 years ago...)
-
Your setup is wrong. It works on my local network with a self signed cert and load balanced servers that include both Windows and Linux servers. (And no, not a troll. I have 5 servers in my house for testing, most of which support vms.)
-
That post makes zero sense.
-
Just be grateful you don't have anything using Java and a self-signed cert, and you upgraded to JRE 8. Nothing in browser will help you, not any more. Off to Java control panel thing with you to manually add exceptions.
-
Wait really? That must have changed, cause it was easy last time I did that... (~2 years ago...)
OK, so technically it's chromium. But I don't think that makes a difference here. I mean, they have a GUI now. But now it's asking for a password for the cert file. WTF...I have no clue. I didn't make this, I just want to use it.
-
I securely encrypted 9 posts to an existing topic: ⛏ isitjustmeorservercooties.com development thread
-
Your setup is wrong. It works on my local network with a self signed cert and load balanced servers that include both Windows and Linux servers. (And no, not a troll. I have 5 servers in my house for testing, most of which support vms.)
What part of the setup? I can't confirm or deny any of that, as I didn't set any of it up and don't have (nor desire) a clue about how to configure https.
What do I need to do to get my damn browser to accept the cert?
-
What's the "other bullshit error"? We might be able to fix it, and it'll stop the torrent of "BULLSHIT NOREPRO"
-
If it's the pfx in visual studio, you can probably delete it and let vs remake it for you. That file is generated during publishing
-
You use Linux correct? That may be the difference.
-
Something once believed impossible was, after enough time, achieved. Not sure what's nonsensical about that...
-
Because there are different types of impossibility?
-
Not really
-
-
There's several routes you can take, you can add the self signed cert to your trusted cert store which will remove all errors for you forever, you can map the local domain in your host file to something like mydomain.dev and add that to your browsers trusted sites
-
What's the "other bullshit error"?
I'm not sure now. When I try to upload the cert now, it's asking me for a password, which I don't remember getting before.
This is using Chromium 41, BTW.
I remember in the past, being able to just click on something to say, "Trust this site." Probably ancient IE or maybe FF. I don't see anything like that any more. I remember looking something up on the web, using wget to fetch some kind of certificate file and then trying to import it into my browser.
I want to say the previous error was something about it not trusting an organization or something.
-
If it's the pfx in visual studio, you can probably delete it and let vs remake it for you.
What? None of that is my browser. Sorry, but this is all gibberish to me.
That file is generated during publishing
This stuff was set up ages ago. The cert itself is dated, like, 2010 - 2021. It's sitting on an apache proxy. I have zero interest in fucking with that. I just want to USE it.
-
Ah. I get it, fundamentally misunderstanding something and not wanting to learn how it works or how to fix it.
Blakey, you're signed in the wrong account
-
He's not using Visual Studio, IE, and IIS Express magic, so your suggestion won't work and being obstinate about it won't help.
Blakey, you're signed in the wrong account.
-
There's several routes you can take, you can add the self signed cert to your trusted cert store which will remove all errors for you forever, you can map the local domain in your host file to something like mydomain.dev and add that to your browsers trusted sites
The server is already mapped in a host file with the server name. I don't see anything resembling "trusted sites" in either chromium or firefox.
-
I get it, fundamentally misunderstanding something and not wanting to learn how it works or how to fix it.
Can you explain what I'm not understanding? I asked about my browser and you started talking about VS and publishing websites.
-
Trusted sites would generally be around security or privacy options, i can look in about 30m
I figured you owned the stack, not accessing a remote site
-
If it's Windows, it's as simple as viewing the cert and clicking "install" I believe. If Linux, I'm sure there's a way to do that too, but I haven't actually done it.
-
Just be grateful you don't have anything using Java and a self-signed cert, and you upgraded to JRE 8. Nothing in browser will help you, not any more. Off to Java control panel thing with you to manually add exceptions.
That's why we have a code signing certificate where I work, because part of our app is a Java Applet.
(Yes, that's a WTF, but it's a third-party component for interacting with Oracle Spatial.)
-
I think they should focus on improving existing security mechanisms rather than trying to force them down their users' throats.
For example, GET RID OF USERNAME AND PASSWORD DIALOGS, let me authenticate to the browser and let the browser authenticate to the page. Or don't 99.9% of sites use email to authenticate your account? Well add some openID-like command to that steaming piece of shit they call SMTP to let me log in directly with my email address. Almost any mechanism like that would be better than what we have.
And this would have the great bonus that your credentials would never travel unencrypted. Then they can deprecate submitting password fields through unencrypted connections, that does make sense.
Also what's with needing certification authorities. Isn't the DNS system already one big authentication authority that knows who owns each domain? Well use it dumbasses. Also Convergence, maybe push that project a little?
-
The fun bit is where almost all government business-facing online services here use hardware tokens + Java. Now, you get the certs on the token / smart card, so that's ok.
But approximately half of them didn't update their manifests and something changed in JRE 8, resulting in their services being broken and requiring manual exceptions for anyone updating their system regularly.
-
I figured you owned the stack, not accessing a remote site
It's my team's stack, but that's not a part I normally touch. I just want the browser to listen to me when I tell it to STFU.
If it's Windows, it's as simple as viewing the cert and clicking "install" I believe.
Yeah, I remember doing that in olden times, but I can't recall which OS / browser it was.
-
http://otherurlthatIknowexistsbutdon'tremember
Autolinkification with a ' in the hostname? Didn't that use to not work?
-
Fun fact: my home router's configuration page is at http://192.168.1.254/. There is no way the manufacturer is going to get a certificate for 192.168.1.254.
Your router also provides your local DNS, correct? DNSSEC solves that problem.
-
Probably not. Is that even valid?
-
Probably not. Is that even valid?
…ts '0' through '9', and the hyphen ('-'). The original specification of hostnames in RFC 952, mandated that labels could not start with a digit or with a hyphen, and must not end with a hyphen. However, a subsequent specification (RFC 1123) permitted hostname labels to start with digits. No other symbols, punctuation characters, or white space are permitted.
It's not valid according to the RFC. It appears to be Discovalid though.
-
That's what I thought.
-
StartSSL is free too
It's free until.....
For example, I have a VPN that runs 5-6 small sites. I wanted to get SSL on all of them... but that meant I had to start paying.
-
Try this for linux (chromium): https://code.google.com/p/chromium/wiki/LinuxCertManagement
Do this for windows: http://blogs.technet.com/b/sbs/archive/2007/04/10/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista.aspxFor linux you can also try this, but i don't know what all the magic voodoo means.
http://blog.avirtualhome.com/adding-ssl-certificates-to-google-chrome-linux-ubuntu/
-
Depends on how you configure it. SNI would allow that. But yeah, wildcard certs cost $60.
-
OK, not sure what they did, but after re-importing and changing the host to match what's on the cert, it seems to work. Thanks.
-
Glad it worked - working with self signed certs isn't actually that hard locally (though some tooling makes it harder than it needs to be) -- I really, really do want to push to a world of all https, if for only the single convenience of never having to worry about mixed content warnings again.
-
I think the issue of not getting there via a normal domain name was causing issues for me with the disconnect between the hostname I gave it and what the cert was saying. And especially the fact that there was no clear error message telling me what the problem was.
-
I think the issue of not getting there via a normal domain name was causing issues for me with the disconnect between the hostname I gave it and what the cert was saying.
This, definitely this. And that's to prevent a cert with a leaked private key being reused for another website by an attacker.@boomzilla said:And especially the fact that there was no clear error message telling me what the problem was.
An unfortunate symptom of fail-early-fail-often, done in the security world as a way to limit exposure to potentially harmful data. Only once you clawed through the this-is-untrusted, this-is-expired, this-is-self-signed, this-doesn't-chain-to-a-root, the-chain-is-broken, etc, etc, errors can you get to the this-is-the-wrong-Common-Name error. 😩
-
An unfortunate symptom of fail-early-fail-often, done in the security world as a way to limit exposure to potentially harmful data. Only once you clawed through the this-is-untrusted, this-is-expired, this-is-self-signed, this-doesn't-chain-to-a-root, the-chain-is-broken, etc, etc, errors can you get to the this-is-the-wrong-Common-Name error.
There are a lot of possible failure modes, and unfortunately they're necessary ones at that. The amazing thing is that it works, and that it's painless for most people almost all of the time.
-
This was my thought. When they deprecate it, presumably they'll start warning users about going to http sites. This will finally kill their browser.
Until Google does the same thing.
Microsoft's browser team seem to be less insane (for example, they're planning to support HTTP-2-without-TLS) so I'd expect them to keep supporting HTTP-1-without-TLS.
Edit: WTF Discourse? I tried to reply to two posts and my first reply got deleted. It was something about how http://httpvshttps.com/ compares HTTP 1 and HTTP 2, which has nothing whatsoever to do with TLS, except that it's a convenient way for Mozilla and Google to push it by confusing people into thinking it makes their connections faster.
-
-
-
But then the first website would be broken
-
Isn't the DNS system already one big authentication authority that knows who owns each domain?
Oh no. No, no, no. If the security of your system depends on the security of DNS, you've already lost.
DNSSEC is a great idea that's very poorly designed. DNSSEC is a perpetual pile of fail, has been since its inception, and the development process shows no signs of excising the fail.
-
It was something about how http://httpvshttps.com/ compares HTTP 1 and HTTP 2, which has nothing whatsoever to do with TLS,
Neither the Firefox folks nor the Chromium folks will support HTTP2 without TLS. As of a month ago, MSFT had not yet shipped a browser that spoke unencrypted HTTP2. They claim that they'll implement cleartext HTTP2, though.