Unfortunately for those who heeded that advice, times are changing, and their internal names may soon conflict with the public DNS. This practice has been recommended by various large software vendors and experts for security, manageability and conflict avoidance. You can read the full text of the letter here:įor many years it has been common practice to configure network services inside the organizational perimeter with suffixes not in the set of publicly-delegated top-level domains. Last week, after speaking with a member of ICANN’s Security and Stability Advisory Committee, Bill Smith and I authored a letter to ICANN expressing our concern with the proposed and potential delegation of certain names, such as “.corp” or “.internal”, that are currently in wide use as de facto internal network names. There were free certificate authorities, but none before included the ease of use and implementation guts.įrom where we are today - maybe all of this looks inevitable - but it has taken a lot of years of concerted work by many parties aligning incentives and making HTTPS-by-default easy - to get where we are today. Let’s Encrypt was started in 2012 with the explicit goal of making it trivially easy to set up, use, and also renew certificates for HTTPS.Google later took an even stronger position - HTTPS would positively impact page-rank.Matt Cutts, Google Page-Rank guru released some statements/ guidance that HTTPS and the slight negative performance impact would not negatively affect page-rank.Adam Langley put out a post - explaining why SSL/TLS was no longer a major performance issue for most use cases.The conventional wisdom among the SEO crowd was that HTTPS hurt your Google page-rank.Īt PayPal we also wanted more of the web to move to HTTPS, and luckily were able to work in concert with Google and several other folks on these topics to address many of people’s general concerns.Purchasing enough certificates/licenses for all of your webservers/domains was still a pretty costly endeavor.There were lots of performance concerns about putting all content behind HTTPS - many believed the costs of HTTPS couldn’t be justified for “public” content. This put us fairly on the cutting edge for the time - many large companies including banks had websites that were mostly HTTP, even the login screen - which submitted to an HTTPS endpoint.įor sites trying to convert universally to HTTPS, there were a few major obstacles: we made the decision to move the whole website to HTTPS for all pages - not just the logged-in ones. In 2007 when I was working at PayPal, after some articles about phishing, downgrade attacks on users, etc. HTTPS was confusing and hard to turn on, and at the time performance was somewhat/ hugely problematic. In the early days you really had to jump through hoops - manually adding modules to your web server (they had to be gotten separately in the Unix world), and some even bigger hoops around getting a certificate which was usually expensive. When it first came out we were mired in the crypto-wars in the US, and deploying encrypted protocols was still very tricky. I was struck by how many pieces and components had to fit together to achieve this big change, and wanted to reflect on a similar change in the security space - the nearly universal adoption of HTTPS for the web. Recently I was reading the book “ The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger ”.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |