<p>Hello gophers!</p>
<p>My mind has been running in circles with TLS scenarios and I thinking maybe some of you might have gone through this and know which way to go would be best.</p>
<p>Basically, there's a Golang Backend, an Angular Frontend running on Nginx or Apache, all behind an Amazon server.</p>
<p>I know you can put TLS on the Amazon Load Balancer, that would mean all requests made to the frontend or backend would be protected as far as I understand ?</p>
<p>If we were to take the Balancer out of the equation, would that mean we'd have to put TLS on both Nginx and the Golang Backend ?</p>
<p>Thanks!</p>
<hr/>**评论：**<br/><br/>tmornini: <pre><p>Here's the simple answer:</p>
<p>EVERYWHERE</p>
<p>TLS is incredibly cheap these days. Use it everywhere, or you'll eventually expose data.</p>
<p>Assuming that any AWS network is "private" enough to run unencrypted data across is trusting yourself, coworkers, and AWS too much.</p>
<p>Did you know that MOST security backs are inside jobs?</p>
<p>Encrypt everything, or you'll eventually regret it.</p></pre>elazarl: <pre><p>Except if <a href="https://xenforo.com/community/threads/adsense-ctr-cut-in-half-after-switching-to-ssl.83732/" rel="nofollow">you want to keep your ads revenue</a>.</p></pre>epiris: <pre><p>I don't really agree with this, it can end up being less secure. If you don't currently have a security product, you soon will after following this advice. If you don't have the expertise or team for it you are asking for a compromise.</p></pre>tmornini: <pre><p>Let me get this straight: encryption causes security issues?</p>
<p>Explain that, please.</p></pre>epiris: <pre><p>I've already been down voted and it's been explained else where. If you want to reduce my comment to "encryption causes security issues" then go for it. I'm not feeding trolls on here anymore. If you really want to learn I'll take the time to explain but add ask a more specific queation and read the other reply I said was a good post first.</p></pre>cittatva: <pre><p>Honestly not trolling, if like to know more about this. Afaik, TLS can be a pain the ads to update certificates and you have to figure out some way to consistently deploy it and make sure it's enforced, but it's the only way to ensure data, like login credentials, isn't transmitted in the clear. If there's info contradicting this or edge cases I'm not thinking about I'd like to know about it. </p></pre>tmornini: <pre><p>Are you talking about complexity? I don't see a link you posted.</p>
<p>Assuming it is complexity, there's little concern is you use automated deployments. Yes, it had to be done correctly and carefully -- but that's a truism for security in general.</p></pre>epiris: <pre><p>Your solution to mitigate the increased surface area of your application from complexity is.. to increase complexity? Okay.</p></pre>tmornini: <pre><p>There is ZERO increased surface area from TLS the way I'd define it.</p>
<p>And if you're now suggesting that automated deployment reduces security, it's obvious you're simply trolling.</p>
<p>Repeatability is, perhaps, the best security tool of all.</p></pre>Redundancy_: <pre><p>Use CloudFront CDN with SSL to an ELB -HTTP-> Go, put your static files on S3</p>
<p>You get:</p>
<ul>
<li>DDOS / malformed request protection & WAF</li>
<li>Caching of static responses and metrics</li>
<li>Automatic updates by Amazon for SSL security patches</li>
<li>Auto-scaling support from the ELB if you need it later (and you bake AMI's etc)</li>
<li>Split traffic between API and content based on path</li>
<li>Don't pay for application servers for static content, upload / update separately</li>
<li>Better global response times and costs for bandwidth</li>
</ul></pre>Adyjay: <pre><p>Thanks, I'll look into that!</p></pre>tmornini: <pre><p>This is fantastic advice, but use HTTPS everywhere.</p>
<p>EDIT: corrected HTTP -> HTTPS as pointed out by <a href="/u/Redundancy_" rel="nofollow">/u/Redundancy_</a> below</p></pre>Redundancy_: <pre><p>I think you meant HTTPS everywhere, so I'll respond to that.</p>
<p>There are a few reasons that I didn't advise that - </p>
<ul>
<li>You should probably be using a VPC with security groups for your application servers, which provides quite a lot of security. Put your ELBs in a VPC with the application, set up your security groups so that the ELB is the only externally accessible entity (only public IPs assigned, only ports open) and do SG-SG port based access for the ELB-App.</li>
<li>If you don't trust AWS, your only solution would be end-to-end encryption that they couldn't cache or route in a CDN. A CDN has to look at the content to work.
<ul>
<li>NB: You really need to make sure that your caching directives (particularly 'private') are set correctly</li>
</ul></li>
<li>If you're not an expert and watching all the advisories, you should probably leave most of your SSL configuration to others, and reduce your stack with the use of managed and correctly configured / updated frontend load-balancers etc.</li>
<li>Using SSL inside your application pushes hostname concerns into your application, which limits your flexibility quite a lot and can force some strange configuration settings.
<ul>
<li>For example: if you have only a single non-wildcard certificate, you'll really twist yourself in knots trying to use it on the CDN, the ELB and the application.</li>
</ul></li>
</ul>
<p>I would personally say that unless you're dealing with something really sensitive (in which case you should be talking to AWS directly and have an Ops/InfoSec team) you've got better things to worry about than AWS and all their security certifications and practices. You can worry about other employees trying to snoop on traffic, but most of the logging available is URL only and locking things like the ELB security groups and DNS down is more valuable, but the application code and things that happen inside the instance are way easier for someone on the inside to get at and do something with, which HTTPS won't help you with. So I'd (personally) be starting with account role security, security groups and instance roles and application code auditing. Please don't give your instances full admin roles, and only let them talk to things that they need to (outgoing is usually a challenge, but you can monitor and alert on that in Cloudwatch logs these days iirc).</p>
<p>Your mileage, requirements and preferences will (of course) vary, so be sure to research and make informed choices yourself based on your needs.</p></pre>epiris: <pre><p>I agree with all of this, great set of posts man. Encrypt at the edge of your network, it can actually be more secure because their is less complexity. A lot of the things you resort to with complete end of end encryption increases the attack surface greatly, SNI, managing certificates and lines of trust.. client cert Auth ends up in the mix. It adds up fast. </p></pre>tmornini: <pre><blockquote>
<p>it can actually be more secure because their is less complexity</p>
</blockquote>
<p>And it is less secure because there is less encryption.</p>
<p>If you want really good security, encrypt everything, and be careful and methodical about it.</p>
<p>Works great when you have 100% automated deployment and you know what you're doing.</p>
<p>The idea that it "can be" more secure because lower complexity is non-sensical and reductionist.</p>
<p>Less is better than more -- except when it isn't.</p></pre>epiris: <pre><p>Oh man, you really shouldn't announce security related things as facts when not a SME. I don't mean offense here, but as someone in IT Security it is very obvious to me and I can pretentiously assert this with confidence based on your two comments in this thread. Please don't take this as a personal attack. You may not think much of it because you have good intent and it sounds reasonable to you but misinformation about security is dangerous. Your comment could be the little piece of empowerment that persuades someone to make a bad security related architectural decision. Just something to consider in the future.</p></pre>tmornini: <pre><p>Ad Hominem, really?</p>
<p>What, EXACTLY, are you suggesting I'm wrong about?</p></pre>Thaxll: <pre><p>Don't use SSL on the Go app, only Nginx.</p></pre>atesushiforlunch: <pre><p>This is really bad advice if the front- and backend happen to run on different servers in a non-private environment.</p></pre>Adyjay: <pre><p>Yeah, that's one of the reasons I'm still not sure how to go with this. </p>
<p>If the server is on Nginx running in 443 (HTTPS) and the Backend on 8080, even if it's the same machine, isn't the JS on the Frontend calling the Backend from the client ? Meaning the data should be encrypted in both cases, but the backend having priority ? </p>
<p>Nginx is basically just serving static files.</p></pre>Tacticus: <pre><blockquote>
<p>Nginx is basically just serving static files.</p>
</blockquote>
<p>SSL prevents tampering as well as providing security.</p></pre>da_rob: <pre><p>To the outside world there is ONLY ONE server. Nginx has to be configured as a reverse proxy to the Go backend, and your users' browsers will only ever talk to Nginx.</p></pre>tmornini: <pre><p>And to skilled hackers, including bad people who work for you, there's all the servers and all the traffic on all the networks.</p>
<p>Security isn't either/or it's all-or-nothing.</p>
<p>Encrypt everything!</p></pre>da_rob: <pre><p>Dude, I'm talking about the "one machine" scenario.</p></pre>tmornini: <pre><p>Haha, apologies. :-)</p></pre>da_rob: <pre><p>No worries, wasn't really clear from this thread.</p></pre>
