HTTPS on Stack Overflow: The End of a Long Road • Hacker News Board

Re: HTTPS on Stack Overflow: The End of a Long Road

#91

Post by astrodust » Mon, May 22, 2017, 10:43 PM UTC

zcdziura wrote: post #66

maddyboo wrote: post #52

Earlier quoted context omitted.

Wow, that sounds ridiculous. What's the reasoning behind that policy?

Seems obvious that someone high up on the corporate ladder, with no practical knowledge in how the nitty-gritty work gets done, made the decision. Probably to "minimize IP theft".

"What do you mean our competitor is using 'for' loops? We invented those!"

Re: HTTPS on Stack Overflow: The End of a Long Road

#92

Post by astrodust » Mon, May 22, 2017, 10:45 PM UTC

mathattack wrote: post #70

Shoop wrote: post #53

Earlier quoted context omitted.

What sort of company do you work at? Why can't everyone just be told not to post code?

In many places (banks) there are legal reasons for this.

This is nothing that can't be addressed through training. Questions on Stack Overflow with generic code actually get better responses than those bogged down with irrelevant details. You should strip out all labels, namess, even extraneous fields that don't matter. It makes for a more generic problem and solution pair that can help others as well, and eliminates the problem of leaking proprietary information.

Re: HTTPS on Stack Overflow: The End of a Long Road

#93

Post by astrodust » Mon, May 22, 2017, 10:46 PM UTC

baby wrote: post #8

kalleboo wrote: post #5

Note to self: Use subdirectories, not subdomains in the future

TLS kills this kind of "cool" features which is kind of sad :( Unless you can afford wildcard certs. What's the argument behind LetsEncrypt not doing that? Extended Validation stuff?

They cost like $199 or less. It's an anoying tax, but they do offer a lot of options, so they're often worth it.

Re: HTTPS on Stack Overflow: The End of a Long Road

#94

Post by astrodust » Mon, May 22, 2017, 10:47 PM UTC

tomschlick wrote: post #37

Side question: any plans for IPv6?

Given the scale of Stack Overflow, you'd think they could set up AAAA records that point to a proper TLS 1.3+ server and leave the peasants on IPv4 going to one that's more...accommodating.

Re: HTTPS on Stack Overflow: The End of a Long Road

#95

Post by alienth » Mon, May 22, 2017, 10:56 PM UTC

tomschlick wrote: post #37

Side question: any plans for IPv6?

Not any immediate plans. Decent amount of development is necessary there. There are so many places in our various systems that work with IP addresses, and many of them don't support v6 addresses.

Re: HTTPS on Stack Overflow: The End of a Long Road

#96

Post by ec109685 » Mon, May 22, 2017, 11:04 PM UTC

alienth wrote: post #95

tomschlick wrote: post #37

Side question: any plans for IPv6?

Not any immediate plans. Decent amount of development is necessary there. There are so many places in our various systems that work with IP addresses, and many of them don't support v6 addresses.

One thing that places do is support IPv6 on the outside and translate to IPv4 calls in the next hop beyond the servers that sit beyond the edge.

Re: HTTPS on Stack Overflow: The End of a Long Road

#97

Post by oefrha » Mon, May 22, 2017, 11:06 PM UTC

niklasrde wrote: post #63

phsource wrote: post #2

This is incredibly detailed; in short, CDNs, cookies/authentication , tons of subdomains, and 3rd-party/user-generated content make it a pain to move onto HTTPS. I was chatting with a non-engineer friend about why it's hard to estimate how long tasks often take, and this seems like a prime illustration: the dependencies are endless. I also love the Easter egg: "The password to our data center is pickles. I didn’t thi…

Just know the username and you can log onto https://stackoverflow.com/admin.php

Warning: link's NSFW.

Re: HTTPS on Stack Overflow: The End of a Long Road

#98

Post by pbarnes_1 » Mon, May 22, 2017, 11:09 PM UTC

quintin wrote: post #34

Has anyone tried running Fastly behind Cloudflare? Are the tradeoffs worth it?

Why would you want to double your CDN costs for negligible benefit?

Re: HTTPS on Stack Overflow: The End of a Long Road

#99

Post by Nick-Craver » Mon, May 22, 2017, 11:10 PM UTC

jontro wrote: post #72

Regarding the section "Mistakes: APIs and .internal" Why wouldn't they use split horizon DNS for this? Seems like the perfect use case

Split horizon would point you at the same data center, rather than the writeable one. So that's more of a .local than a .internal. We discussed this, but ultimately the AD version we're on (pre-2016 Geo-DNS) it's not actually supported the way you'd need, and it's a nightmare to debug.

We'd consider it for a .local, when the support it properly there in 2016. Even subnet prioritization is busted internally, so that's a bit of an issue. Evidently no one tried to use a wildcard with dual records on 2 subnets before (we prioritize the /16, which is a data center) and it's totally busted. Microsoft has simply said this isn't supported and won't be fixed. A records work, unless they're a wildcard. So specifically, the .stackexchange.com record which we mirror internally at .stackexchange.com.internal for that IP set is particularly problematic.

TL;DR: Microsoft AD DNS is busted and they have no intention of fixing it. It's not worth it to try and work around it.

Re: HTTPS on Stack Overflow: The End of a Long Road

#100

Post by cortesoft » Mon, May 22, 2017, 11:11 PM UTC

baby wrote: post #84

cortesoft wrote: post #82

Earlier quoted context omitted.

How would they prove that you own every subdomain?

I'm not sure I understand the question. If you own something.com then you automatically own any possible subdomains.

The Let's Encrypt process is about validating control of the content on a domain, not about OWNERSHIP of the domain. To get a cert, you just have to be able to update a file at a Let's Encrypt specified location on the domain. This is only proving that you are in control of the website for that specific domain, not that you are in control of the DNS for the entire domain and all subdomains.

Of course if I own a domain, I own all the subdomains. However, being in control of the site served at port 80 for a domain does not mean I own it.