Uploaded byHeroku
Creating Secure Web Apps: What Every Developer Needs to Know About HTTPS Today
The webinar discusses the importance of HTTPS for web security, emphasizing the need for automated, free, and easily accessible certificates through initiatives like Let's Encrypt. It highlights the risks of data privacy and integrity, and provides practical tips for developers to implement HTTPS effectively. The session concludes with the message that server authentication and integrity are critical for the web's continued success and encourages sharing knowledge with others.
More Related Content
Similar to Creating Secure Web Apps: What Every Developer Needs to Know About HTTPS Today
Creating Secure Web Apps: What Every Developer Needs to Know About HTTPS Today
- 1. Creating Secure WebApps: What Every Developer Needs to Know About HTTPS Today Josh Aas, Executive Director, Internet Security Research Group Brett Goulder, Product Manager, Heroku Chris Castle, Developer Advocate, Heroku Wednesday, June 14, 2017
- 2. Josh Aas, Executive Director, InternetSecurity Research Group @0xjosh Brett Goulder, Product Manager, Heroku @brettgoulder Chris Castle, Developer Advocate, Heroku @crc
- 3. Some Logistics… • 20minutes at the end for Q&A • Submit questions throughout webinar in “Questions” box • Audio / video problems? Click raise hand button or use “Help” menu
- 4. What are Let’sEncrypt and Heroku Doing to Promote Web Security?
- 5. Initial Idea •Summer 2012 •Need100% HTTPS •Not pay-to-play •HTTPS must be easy
- 6.
- 7.
- 8. Automated Certificate Management Source:https://vimeo.com/208872579
- 9.
- 10.
- 11. Google Chrome Telemetry Source:https://www.google.com/transparencyreport/https/metrics/
- 12. Why This Webinar? Reducecomplexity Image: Hans Eiskonen, https://unsplash.com/@eiskonen
- 13. Why This Webinar? Educateothers Image: Štefan Štefančík, https://unsplash.com/@cikstefan
- 14. What Are TheRisks?
- 15. Data Privacy • FinancialInformation • Health Information • Passwords
- 16.
- 17.
- 18. Sender Authenticity Image: JamesSutton, https://unsplash.com/@jamessutton_photography Who am I talking to?
- 19. How Does HTTPSAddress These?
- 20.
- 21.
- 22.
- 23. So what doesthat mean in practice? 1. No one can view data in-transit 2. No one can modify data in-transit 3. Data is coming from domain in URL bar
- 24.
- 25.
- 26. Some Carrots andSome Sticks
- 27.
- 28.
- 29. HTTPS Preferred InSearch Ranking
- 30.
- 31.
- 32. HTTPS Tips ForDevelopers
- 33. Google Transparency Report Source:https://www.google.com/transparencyreport/https/grid/
- 34. ✔ Works onHTTPS ✔ ✔ Modern TLS Config Default HTTPS
- 35. Start With HTTPS ❌✔Images: LoboStudio Hamburg, https://unsplash.com/@lobostudiohamburg
- 36. All Resources UseHTTPS
- 37. Use Modern TLS RSA DH ECDH RSA DSA ECDSA AES 3DES CAMELLIA SHA MD5 Checkwhat your browser supports at https://www.ssllabs.com/ssltest/viewMyClient.html
- 38. Redirect All HTTPto HTTPS
- 39. Use HTTP StrictTransport Security (HSTS)
- 40. Use Content SecurityPolicy
- 41. Resources • SSL LabsSSL Server Test https://www.ssllabs.com/ssltest/ • Mozilla Observatory https://observatory.mozilla.org/ • See What Incorrect SSL Configuration Looks Like in Browser https://badssl.com/ • Mozilla Web Security Guidelines https://wiki.mozilla.org/Security/Guidelines/Web_Security • Google Web Fundamentals – Security and Identity https://developers.google.com/web/fundamentals/security/ • High Performance Browser Networking, TLS Chapter https://hpbn.co/transport-layer-security-tls/ • Discussion of TLS speed concerns https://istlsfastyet.com/
- 42.
- 43.
- 44. …the Web’s trustworthinesshas become critical to its success. If a person cannot trust that they are communicating with the party they intend, they can’t use the Web to shop safely; if they cannot be assured that Web-delivered news isn’t modified in transit, they won’t trust it as much. If someone cannot be assured that they’re talking only to the intended recipients, they might avoid social networking. Source: https://www.w3.org/2001/tag/doc/web-https
- 45. This leads usto a conclusion that server authentication and integrity are baseline requirements for the continued success of the Web… Source: https://www.w3.org/2001/tag/doc/web-https
- 46. Summary • We’re onlyhalf-way there • Use these tips today • Share with others
- 47.
- 48. Q&A Josh Aas, Executive Director, InternetSecurity Research Group @0xjosh Brett Goulder, Product Manager, Heroku @brettgoulder Chris Castle, Developer Advocate, Heroku @crc
Editor's Notes
- #2 Hello everyone. Welcome and thanks for joining us! We’re going to talk about Creating Secure Web Apps today. Hope you’re excited for an educational, developer-focused talk about the importance of web security and what you can do to help advance it.
- #3 But who is “we”? That would be Josh, Brett, and me, Chris. Josh, can you introduce yourself? Hi I’m Josh Aas, Executive Director of the Internet Security Research Group and Founder of Let’s Encrypt. Great, Brett? Hi, I’m Brett Goulder, Product Manager at Heroku. Great, and again, I’m Chris Castle, and I’m a Developer Advocate at Heroku.
- #4 Some logistics before we start up.
- #5 Change this to be more of an intro section describing a little more about Let’s Encrypt and Heroku? Vik had thoughts here…
- #6 [JOSH] Let’s Encrypt was born from…
- #7 Our vision was…
- #8 [CHRIS] For several years Heroku has provided free HTTPS for all applications with a *.herokuapp.com subdomain. This means every application deployed to Heroku automatically gets HTTPS. But many people want to customize their domain.
- #9 In March, we released Automated Certificate Management to make it easier to use a custom domain with HTTPS. In fact, it’s not just easier, there are no extra steps. You specify your custom domain and we automatically setup your certificate. Check this out. SHOW VIDEO AND NARRATE WHAT’S HAPPENING https://vimeo.com/208872579 Heroku automatically acquires and manages renewal of a certificate for custom domains on paid Heroku apps. And this wouldn’t have been possible without Let’s Encrypt.
- #10 [JOSH] So first let’s set some context: why are we doing this webinar?
- #11 …well there are still a lot of websites not using HTTPS. Here’s browser telemetry data from Firefox. During the 24 hours of June 7th, just one week ago, only 57% of the web pages loaded by Firefox using HTTPS. You can see that’s the best day since November 2015. And you can also see the slope is not very steep. Over this time range, it’s going up at only 7.4 percentage points per year. At that rate it will take over 5 years to get to 100%. It should be 100% now. In fact, it should have been 100% years ago.
- #12 Chrome data confirms that adoption rate and growth. So if developers think HTTPS is simple, why aren’t more pages using it? Maybe implementing it is more complicated than we think. Well, what can we do about that? This webinar is one thing we’re trying.
- #13 [CHRIS] We’re doing this webinar because we want to educate developers and help them cut through the complexity.
- #14 We also want to help you educate others about web security. We aren’t going to get to 100% with the couple hundred people on this webinar! Answer your colleagues’ questions and encourage them to use HTTPS by default.
- #15 [JOSH] So we’ve explained why we’re doing this webinar: we want the web to be at 100% HTTPS, But why is that? What are the risks with unencrypted HTTP? Well, they can be described by 3 categories:
- #16 First: data privacy. Privacy of sensitive data like your financial information, health information, and the passwords that protect these. Most developers know this Many non-developers know this (i.e. if I’m going to do something with private data on the web, I look for the padlock icon) Many people think this is the only purpose of HTTPS.
- #17 But privacy of your other web activity is also important: news articles you read, products you buy, topics you research, videos you watch. This data aggregated provides a very detailed, personal, and accurate profile of you. Some may be ok with that, but it should be a choice. With unencrypted HTTP, you have no choice. Nor do you know who may be creating a profile of you. Change title to "meta data privacy"
- #18 Second is data integrity. Did you know that on public wifi, it’s very easy for any HTTP web page to be manipulated before it gets to your browser? How easy you might ask? On public wifi, something like what’s shown in this screenshot can be done easily with a small device like a Raspberry Pi. And in fact, it doesn’t even matter if you’re on public wifi. Any page delivered using HTTP can be modified inconspicuously before it gets to your browser.
- #19 Third: data authenticity Authenticity – unencrypted HTTP provides no guarantees that the page you’re viewing is in fact coming from the domain in the URL bar. Telephone metaphor.
- #20 [CHRIS] So how does HTTPS address these three issues?
- #21 For data privacy, the body of all requests and responses is encrypted. I think most developers know this. But what about HTTP information – the meta data included in each HTTP request and response like the domain, path, querystring, user agent, etc. What exactly is encrypted? Is the URL encrypted? Query string parameters? Other headers? Here is an example HTTP request. And here is what is hidden by HTTPS.
- #22 Data integrity is also guaranteed by HTTPS. A ”message authentication code” is calculated and sent along with the message. It is calculated using the message and a secret key as inputs. Only the sender and receiver know the secret key used to calculate the code. If the code calculated by the receiver doesn’t match the code received from the sender, an error occurs.
- #23 Finally, data authenticity is guaranteed. If the certificate is valid and the certificate domain matches the request domain, then you can be sure the page is coming from that domain.
- #25 If you know HTTPS well, those three sentences might have made you a little uncomfortable. Like most things related to encryption, the devil is in the details. Unfortunately, it is not as simple as pushing a button to get those three guarantees.
- #26 If it were simple, we’d be much closer to 100% adoption by now.
- #27 [JOSH] So we have these incentives, some “carrots”, some “sticks”, to encourage more website developers to use HTTPS.
- #28 More than 2 years ago, Mozilla stated their intent to “phase out” non-secure HTTP Focusing new development efforts on the secure web only. And even stating that they will remove capabilities from the non-secure web.
- #29 Chrome’s HTTP deprecation has taken the form of marking HTTP pages with password or credit card fields as not secure. And Google has said Chrome will mark all HTTP pages as Not Secure in the future.
- #30 Google has adjusted it’s indexing system to look for more HTTPS pages and prefer them over equivalent HTTP pages.
- #31 Some sensitive browser features, such as the geolocation API now require HTTPS in Chrome and Safari.
- #32 Using the computer’s camera or microphone (getUserMedia) is another example that requires HTTPS.
- #33 [CHRIS] So, given the importance of HTTPS and the changes browsers are making to encourage HTTPS, what can you do? Here are some recommendations you can apply to both new sites or sites you currently work on.
- #34 First, a good resource to see what sites are doing it well is the Google Transparency report. It lists the HTTPS status of the top 100 non-Google sites.
- #35 It qualifies secure websites with three checks: Does the site work on HTTPS? And does it work without any browser warnings? Does it use a modern TLS configuration. This means the site offers TLS 1.2 and a cipher suite that uses an AEAD mode of operation. Does it default to HTTPS. Defaulting to HTTPS means redirecting all HTTP requests to HTTPS.
- #36 Design your application to use HTTPS from the start
- #37 All resources (e.g. images, JS, CSS) a page loads should use HTTPS — whether external or not
- #38 Use modern TLS (and what is the difference between SSL and TLS?) SSL is deprecated TLS has gone through several revisions. Currently TLS 1.2, 1.3 being drafted. ”Cipher suite” means different things in TLS 1.3 and TLS < 1.3 https://en.wikipedia.org/wiki/Cipher_suite
- #39 Redirect all HTTP requests to HTTPS
- #40 HSTS is a response header you set on the server It instructs the browser that all future connections to this site should only be HTTPS If the browser goes to this site in the future and it’s unencrypted HTTP, it’s likely something is trying to intercept the connection HSTS can be implemented in report-only mode before being fully turned on You can specify a time after which the browser will forget this instruction (think of this like a DNS record TTL) You can also specify whether to include subdomains and whether to use a preload list maintained by the browser vendor
- #41 Content Security Policy is another response header that helps to prevent cross-site-scripting, click jacking, and other code injection attacks It does this by allowing the website owner to specify approved origins of content to load on a page. There are two policies that help with upgrading sites from HTTP to HTTPS One is upgrade-insecure-requests. This tells the browser to automatically rewrite any HTTP URLs in the page to HTTPS The other is block-all-mixed-content. This prevents any HTTP resource URLs from being loaded on a page delivered over HTTPS
- #42 Here are some great resources for you to use and share. SSL Labs SSL Server Test and Mozilla Observatory will help you grade your website on the path to proper HTTPS configuration. The rest are great resources to learn more… to answer a specific question or dig in deeper on a topic you want to know more about.
- #44 In early 2015, the W3C technical advisory group released a document about securing the web using cryptography. It’s intended audience was W3C participants – the people working to define web standards. Reading this document now, more than two years later, it’s clear that its message is important for all developers to understand. I encourage to read it, but I wanted to highlight two paragraphs here.
- #45 [READ QUOTE]
- #46 [READ QUOTE]