Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTPS on Stack Overflow: The End of a Long Road

nickcraver.com

Post reply on HN
Print view View original

171–180 of 183 posts

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

#171

Post by kbart »

dzdt wrote: post #49

Stack Exchange is no longer available from my workplace due to this change. We have a strict no-posting-code-fragments policy, and SE was viewed as too risky to allow without some restriction in place to make it read only. Before HTTPS, the IT department had worked out such a read-only restriction by blocking the SE login with firewall rules. But with HTTPS that kludge is no longer possible, so the site is blocked.

Sorry, but such policy is just stupid. There are many, many ways one could get a snapshot of code without posting it online. I respect SE for their decision to make things right, not kneel down against costumers and their faulty "security" practices which can be often seen.

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

#172

Post by gub09 »

It would be better if scripts like jquery were not encrypted. This forces users to use e.g. a google service instead of caching/hosting the scripts themselves or getting them from another CDN. I do not understand why so many people do not consider the privacy implications of every single webpage requiring calls to google services. There are ways to avoid this, but it gets a lot more complicated when that requires MITM methods for SSL. Please: use a non-tracking CDN, host it yourself, or at least leave it HTTP.

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

#173

Post by tyleraldrich »

lucb1e wrote: post #142
linkregister wrote: post #128

Earlier quoted context omitted.

Thanks for the correction! I am asking pretty niche questions.

I feel you. I've taught myself programming between 13 and, well, I'm now 23; so by the time stackoverflow came around I had figured out how to solve things myself. When I have a question, it's usually either opinion-based (bad fit for SO) or not a common question. I'd say 1:20 is a good estimate if I ignore answers that didn't read my question (which is most of them), but indeed the facts disagree.

What? Stackoverflow has been around since ~2008 - You certainly didn't learn how to solve things yourself a year into programming :).

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

#174

Post by eridius »

poizan42 wrote: post #164
eridius wrote: post #38

Earlier quoted context omitted.

There's a long StackExchange answer about this: https://security.stackexchange.com/a/158164 But it boils down to there being no practical way for Let's Encrypt to automatically validate that a wildcard certificate is safe to issue.

It's a long answer that completely fails to address the possibility of validating ownership of the domain itself by e.g. adding a TXT record, which the ACME protocol already supports.

The general point is that being able to control the parent domain doesn't necessarily mean you control all possible subdomains as well. You need to prove ownership, not just control. Here's the relevant bit from the SO answer:

> If I have ownership of the parent domain example.com then I can freely create and control anything as a subdomain, at any level I choose. Note that here "ownership" is distinct from "control", which is what is validated by the ACME protocol.

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

#175

Post by michaelt »

make3 wrote: post #129
boyter wrote: post #69

Earlier quoted context omitted.

Same thing happened to me at a workplace once. They blocked StackOverflow, GitHub, Bitbucket, Sourceforge, CodePlex and Google Code. I told them all estimates go up by 2 years since we would need to reimplement everything. It ended up being unblocked a week later.

This sounds beyond absurd to me. Do they also block usb ports to prevent you from copying everything on a usb drive or external harddrive, or phone? Do they lock/solder you machines shut to prevent you from taking out a hard drive / plugging in a new one and then taking it out? Do they prevent you from .. printing the code? In what parallel world do they exist that they think this would make a difference

A few years ago, I interviewed at a company called 'G Research' and the security procedures I noticed included:

* A 'secure zone' where work took place.

* All desktops virtualised, using thin clients.

* All Windows, no admin access.

* Screens, filesystem snapshots, and web access recorded, all the time.

* All software installation subject to approval (e.g. Firefox not permitted, only Chrome).

* Desks fixed in place, all cables in locked cable trays.

* Separate internal-only e-mail system.

* No printers.

* Specially printed notepads & other stationary in the 'secure zone', no secure zone stationary to leave or non-secure-zone stationary to enter.

* No cell phones, cameras or laptops permitted (lockers were provided).

* Entry points with human guards and metal detectors.

* No late working outside guards' hours.

While it would have been possible to get around the security if you were inventive enough (e.g. camera with no metal parts) it would be difficult to do so then believably claim it was an accident.

I didn't take the job, because I didn't feel I could be productive with so much bureaucracy.

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

#176

Post by sofaofthedamned »

laughingman2 wrote: post #145
sofaofthedamned wrote: post #144

Earlier quoted context omitted.

Had a similar one at my last role. It was a HTML5 remote desktop thing with websockets, TLS1.2 etc etc. Got a bug report from a user that it didn't work in Safari. We didn't have a Mac in the office to test with, so asked the user for more details. "Oh no, this isn't a Mac, it's Windows" This is a user of a highly secure system, containing user PII, who expected to use it on a 5 year old browser with XP. ~bangs head~

In unrelated to topic note, I am in a team making html5 remote desktop thingie, I have to now start making the linux agent. If its alright for you to answer, 1. What would be the best/cross platform way to proceed?We now have separate agents for windows, mac which causes maintenance hell 2. Is chrome remote's way of streaming desktop images as video better than images + diff. 3. Is there any open source mirror driver…

The software used was a commercial tool made upon Guacamole (Apache) called Inuvika. It's pretty awful, but having Linux and Windows apps on the same virtual desktop is quite cool. I don't know how much of that functionality comes from Guacamole or from the Inuvika addons.

Inuvika/Guacamole also support plain RDP, but we didn't use this, just the html5 client (browser)

If you want to see what open-source can do then look at Guacamole and go from there.

Don't think that helps, but...

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

#177

Post by lucb1e »

tyleraldrich wrote: post #173
lucb1e wrote: post #142

Earlier quoted context omitted.

I feel you. I've taught myself programming between 13 and, well, I'm now 23; so by the time stackoverflow came around I had figured out how to solve things myself. When I have a question, it's usually either opinion-based (bad fit for SO) or not a common question. I'd say 1:20 is a good estimate if I ignore answers that didn't read my question (which is most of them), but indeed the facts disagree.

What? Stackoverflow has been around since ~2008 - You certainly didn't learn how to solve things yourself a year into programming :).

Back then I didn't speak proper English, and how many questions were actually covered on SO in the beginning? It took some years to get to where we are, both for SO and for my English ;)

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

#178

Post by astrodust »

RangerScience wrote: post #118
astrodust wrote: post #92

Earlier quoted context omitted.

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.

Maybe about half the time I end up answering my own question during this step. The act of genericizing the question ends up giving me some new approach, which either works, or leads me to new existing questions-and-answers.

Yeah. When you remove all the confusion, the problem is usually pretty obvious.

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

#179

Post by ajdlinux »

lostboys67 wrote: post #159
ajdlinux wrote: post #117

Earlier quoted context omitted.

Not if they're forced to check their phones in. I have friends working in the defence industry for whom this is something they have to deal with.

Well sites doing TS work you can sort of understand that I knew someone who worked for the scientific civil eservice and they where not allowed to have a phone with a camera. I have also been for an interview at a site (HMGC) where you have to hand in all electronics at reception - this was an avowed role btw so I am not breaking any laws the organisation even has job adverts on the local buses

Not even TS work - it can include lower level classifications too.

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

#180

Post by mrunkel »

mattmanser wrote: post #39
mrunkel wrote: post #7

At $previous_job we once turned on HTTPS for our entire customer website and online store, only to have our customer support team be bombarded by phone calls claiming that our "website was down." After much teeth gnashing and research, we determined that a large segment of our user base was still using WinXP and the encryption protocols we offered weren't available to them. We didn't think this would be a problem bec…

I know it's hindsight and all that, but why didn't you check your website analytics first? Seems a fairly massive assumption that should have taken 10 seconds to check.

That would have been really smart. However, this move was driven by the product owner, including the requirement that we must score an "A" on the SSL Test site. I had just assumed he knew what he was asking for.

The scanning of the server logs occurred to us in hindsight as well.

Post reply on HN