Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on May 6, 2018 11:07:01 GMT
Your link only evidences that an organization such as the NSA could viably intercept the traffic, and if they really wanted to, they could just do it anyway with the support of Cloudflare. Using any of the options will prevent against a MiTM attack between your PC and the Cloudflare edge routers, which is the main risk we're trying to mitigate here and even then I'd argue that there are very very few people on these forums I think could complete a MiTM attack anyway, and even fewer that could do it without it being detected. It also doesnt mitigate against the entirety of MiTM anyway as you can still perform a MiTM attack even with cloudflare on its full / strict settings if you own / have breached the internal network you're coming out of, as you can force a fake certificate to be signed between the client and yourselves, and then you simply pass the traffic on to Cloudlfare. In reality the risk you're talking about here is exponentially slim and the vast majority of the issues and risks you would be trying to mitigate you do just by having Cloudflare on Flexible. Its also worth noting that even if we moved off of Cloudflare unless we've enabled HSTS and transferred the domain with us (And I cant see proboards giving us their domain), you can get new SSL Certificates issued for the new domain anyway. Ultimately we should be trying to force everyone through the https version of the site as there is no logical reason not to... Yes, you are correct about the improbability of a nation-state MiTM attack. More than likely, the courts will force ProBoards to do XYZ without involving CloudFlare. If you read my later comments, you can see that I said there is no reason (little reason) not to use the SSL. It's later and not in the original post. I fully understand what you are saying and agree with it. It's just healthy to provide the other side of the argument. As for clarification, CloudFlare has three configurations: flexible, full, and strict. Flexible will enable severs that have no SSL to appear as it does. Full will enable severs with self-signed and or misconfigured certificates to appear as legitimate but if the traffic is unencrypted and does not have any SSL it'll be invalid. Lastly, strict will force a properly managed certificate from a verified CA. I mentioned the possibility of losing the compatibility and this is the only concern I have. If users bookmarked the SSL version of the website and we lost the SSL compatibility the users would error. Potentially even a disconnection depending on how ProBoards handles the situation. Regardless, some will be confused and simply not use our forums. Managing this issue is entirely outside our abilities and really isn't something we can prepare for. Any website that requires login details should have SSL. We are no exception. Compatibility wise is ultimately out of our control, and I cannot see it being likely Proboards would roll back allowing SSL Access, and even if they did the issue is limited to bookmarks hopefully. The only time it becomes a real pain (And it'd be a pain for the entire of boards.net in this case) is if they enabled HSTS and added boards.net to the preload list, at that point you're royally fucked as the browser would not allow a non-ssl version of the site to be served. Though again, I think the realistic risk of that is slim. As for the nation-state MiTM attack, if they wanted to get to a board like this, they'd simply go to Proboards and have it killed... We're not a massive forum, we're not doing anything illegal / flagging worthy, so its realistically a risk we should just be going "Well it could happen... But pigs could also fly". Thats just my 2 cent on the matter, but I certainly think we should force https where possible, and if we controlled our own domain I'd enable HSTS as well and ideally get it preloaded into browsers.
|
|
Cowgomooo12
Club 4000 Member
Vaarwel, afscheid
Posts: 4,894
| Likes: 5,266
|
Post by Cowgomooo12 on May 6, 2018 11:12:01 GMT
Yes, you are correct about the improbability of a nation-state MiTM attack. More than likely, the courts will force ProBoards to do XYZ without involving CloudFlare. If you read my later comments, you can see that I said there is no reason (little reason) not to use the SSL. It's later and not in the original post. I fully understand what you are saying and agree with it. It's just healthy to provide the other side of the argument. As for clarification, CloudFlare has three configurations: flexible, full, and strict. Flexible will enable severs that have no SSL to appear as it does. Full will enable severs with self-signed and or misconfigured certificates to appear as legitimate but if the traffic is unencrypted and does not have any SSL it'll be invalid. Lastly, strict will force a properly managed certificate from a verified CA. I mentioned the possibility of losing the compatibility and this is the only concern I have. If users bookmarked the SSL version of the website and we lost the SSL compatibility the users would error. Potentially even a disconnection depending on how ProBoards handles the situation. Regardless, some will be confused and simply not use our forums. Managing this issue is entirely outside our abilities and really isn't something we can prepare for. Any website that requires login details should have SSL. We are no exception. Compatibility wise is ultimately out of our control, and I cannot see it being likely Proboards would roll back allowing SSL Access, and even if they did the issue is limited to bookmarks hopefully. The only time it becomes a real pain (And it'd be a pain for the entire of boards.net in this case) is if they enabled HSTS and added boards.net to the preload list, at that point you're royally fucked as the browser would not allow a non-ssl version of the site to be served. Though again, I think the realistic risk of that is slim. As for the nation-state MiTM attack, if they wanted to get to a board like this, they'd simply go to Proboards and have it killed... We're not a massive forum, we're not doing anything illegal / flagging worthy, so its realistically a risk we should just be going "Well it could happen... But pigs could also fly". Thats just my 2 cent on the matter, but I certainly think we should force https where possible, and if we controlled our own domain I'd enable HSTS as well and ideally get it preloaded into browsers. I'm thinking PB wouldn't enable HSTS unless it had the intention of keeping SSL forever (or until it closes). Businesses don't typically hurt themselves. HSTS would kill their business if they forced SSL and didn't support it. To my understanding with preloading, HSTS applies automatically and there would be entirely automatically pushed to the SSL version. Am I making sense or speaking jibberish?
|
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on May 6, 2018 11:16:55 GMT
Compatibility wise is ultimately out of our control, and I cannot see it being likely Proboards would roll back allowing SSL Access, and even if they did the issue is limited to bookmarks hopefully. The only time it becomes a real pain (And it'd be a pain for the entire of boards.net in this case) is if they enabled HSTS and added boards.net to the preload list, at that point you're royally fucked as the browser would not allow a non-ssl version of the site to be served. Though again, I think the realistic risk of that is slim. As for the nation-state MiTM attack, if they wanted to get to a board like this, they'd simply go to Proboards and have it killed... We're not a massive forum, we're not doing anything illegal / flagging worthy, so its realistically a risk we should just be going "Well it could happen... But pigs could also fly". Thats just my 2 cent on the matter, but I certainly think we should force https where possible, and if we controlled our own domain I'd enable HSTS as well and ideally get it preloaded into browsers. I'm thinking PB wouldn't enable HSTS unless it had the intention of keeping SSL forever (or until it closes). Businesses don't typically hurt themselves. HSTS would kill their business if they forced SSL and didn't support it. To my understanding with preloading, HSTS applies automatically and there would be entirely automatically pushed to the SSL version. Am I making sense or speaking jibberish? No you're 100% right I think. It depends on the company, the project I am working on at work for one of our customers have just rolled out HSTS for their root domain, and added it to the preload list, meaning any services on it now must support https or it just wont work, which is great and it is the way we should be doing things. What I suspect proboards would do is enable HSTS on their root domains and not delegate that to sub-domains (The same for pre-loading) and ideally give people a choice to enroll on it, though saying that it is possible to delete a forum and then make a new one with the same name, but if Proboards always own the SSL for it, you could still HSTS and preload it and force that for everyone. I cant see them doing that, but that would be the ideal situation. If we want to have control over such things we would need to move to our own domain and move the forums with it (Something we looked at doing in the past but was rushed beyond rushed, though if we can get enough people with the skills to do it would be worth while doing). You are right though, if they just enabled HSTS and preloaded it without any sort of support or testing it, it'd kill their entire business in this case, its why generally businesses will phase in HSTS and then preload it when the tests have been a success and the HSTS is set to like a 1 year remember period.
|
|
Cowgomooo12
Club 4000 Member
Vaarwel, afscheid
Posts: 4,894
| Likes: 5,266
|
Post by Cowgomooo12 on May 6, 2018 11:25:29 GMT
I'm thinking PB wouldn't enable HSTS unless it had the intention of keeping SSL forever (or until it closes). Businesses don't typically hurt themselves. HSTS would kill their business if they forced SSL and didn't support it. To my understanding with preloading, HSTS applies automatically and there would be entirely automatically pushed to the SSL version. Am I making sense or speaking jibberish? No you're 100% right I think. It depends on the company, the project I am working on at work for one of our customers have just rolled out HSTS for their root domain, and added it to the preload list, meaning any services on it now must support https or it just wont work, which is great and it is the way we should be doing things. What I suspect proboards would do is enable HSTS on their root domains and not delegate that to sub-domains (The same for pre-loading) and ideally give people a choice to enroll on it, though saying that it is possible to delete a forum and then make a new one with the same name, but if Proboards always own the SSL for it, you could still HSTS and preload it and force that for everyone. I cant see them doing that, but that would be the ideal situation. If we want to have control over such things we would need to move to our own domain and move the forums with it (Something we looked at doing in the past but was rushed beyond rushed, though if we can get enough people with the skills to do it would be worth while doing). You are right though, if they just enabled HSTS and preloaded it without any sort of support or testing it, it'd kill their entire business in this case, its why generally businesses will phase in HSTS and then preload it when the tests have been a success and the HSTS is set to like a 1 year remember period. Let's Encrypt enabled wildcat domains, so the cost and configuration is marginal. The issue would be people attempting www.totalfreedom.boards.net. as the wildcat would not support two level deep subdomains. HSTS, if they have the intention on keeping SSL for life, should be enabled on all subdomains. The concern is will they keep SSL for life. In the proposal the flag for subdomains is optional tools.ietf.org/html/rfc6797#section-6.1.2-- Preloading just means that your browser has a list of websites that are already known to force SSL and tells the browser ONLY connect if it's using SSL. Without preloading, the moment a client exchanges it's first handshake the server declares it follows RFC 6797 and the browser will say "OK!" and force all connections to be SSL. Preloading prevents a MiTM attack from the original (first) connection as the packets cannot he tampered to drop the 'declaration of RFC 6797'. For initial development, the web master will configure the HSTS time to be mere seconds or minutes rather than the recommended 6 to 12 months.
|
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on May 6, 2018 14:15:39 GMT
No you're 100% right I think. It depends on the company, the project I am working on at work for one of our customers have just rolled out HSTS for their root domain, and added it to the preload list, meaning any services on it now must support https or it just wont work, which is great and it is the way we should be doing things. What I suspect proboards would do is enable HSTS on their root domains and not delegate that to sub-domains (The same for pre-loading) and ideally give people a choice to enroll on it, though saying that it is possible to delete a forum and then make a new one with the same name, but if Proboards always own the SSL for it, you could still HSTS and preload it and force that for everyone. I cant see them doing that, but that would be the ideal situation. If we want to have control over such things we would need to move to our own domain and move the forums with it (Something we looked at doing in the past but was rushed beyond rushed, though if we can get enough people with the skills to do it would be worth while doing). You are right though, if they just enabled HSTS and preloaded it without any sort of support or testing it, it'd kill their entire business in this case, its why generally businesses will phase in HSTS and then preload it when the tests have been a success and the HSTS is set to like a 1 year remember period. Let's Encrypt enabled wildcat domains, so the cost and configuration is marginal. The issue would be people attempting www.totalfreedom.boards.net. as the wildcat would not support two level deep subdomains. HSTS, if they have the intention on keeping SSL for life, should be enabled on all subdomains. The concern is will they keep SSL for life. In the proposal the flag for subdomains is optional tools.ietf.org/html/rfc6797#section-6.1.2-- Preloading just means that your browser has a list of websites that are already known to force SSL and tells the browser ONLY connect if it's using SSL. Without preloading, the moment a client exchanges it's first handshake the server declares it follows RFC 6797 and the browser will say "OK!" and force all connections to be SSL. Preloading prevents a MiTM attack from the original (first) connection as the packets cannot he tampered to drop the 'declaration of RFC 6797'. For initial development, the web master will configure the HSTS time to be mere seconds or minutes rather than the recommended 6 to 12 months. There would be no reason you couldnt use letsencrypt with sub-domains directly anyway. Its how we manage it for our customer, because there are a lot of teams on different sub-domains and management of the sub-domains are delegated to other teams to manage their own DNS you just set your own SSL Certs up and HSTS just lives with it. As long as everyone uses the same CA you're fine (Or agreed list anyway I should say). Preloading is an optional extra, it just is a sensible thing to do if you're going to enable HSTS anyway in my opinion. And yes you are right, you do not need to enable HSTS for sub-domains, but it is optional, that was what I was trying to say before but dont think I worded it super well...
|
|