Say you're looking for a job, and you want a portfolio you can show to prospective employers who "don’t interview anyone who hasn’t accomplished anything."[1] If your portfolio involves web development, you'll need hosting for your projects.
The consensus among Slashdot users as of the fourth quarter of 2012 is that WebFaction is the way to go. It supports Python and PostgreSQL in addition to PHP and MySQL, and it even supports SNI so that you can secure user credentials for users of non-obsolete web browsers. But in 2016, with WebFaction's lag in support for the Let's Encrypt CA, DreamHost is gaining on WebFaction.
HTTP normally allows any eavesdropper to see the entire transaction. This means that anyone with access to the packets on a network can use something like Firesheep to intercept session cookies of other users on the same subnet and then forge them to impersonate another user. To prevent this, HTTP is commonly tunneled over Transport Layer Security (TLS), formerly called Secure Sockets Layer (SSL), to form HTTPS. If your one of your projects involves user accounts, you'll need hosting that includes HTTPS so that users can't intercept others' cookies. Since the Firesheep tool began to raise awareness of cookie theft, the Electronic Frontier Foundation has been distributing an extension called HTTPS Everywhere for the Firefox and Chrome web browsers that automatically rewrites HTTP URLs to the corresponding HTTPS URLs on sites known to support HTTPS.
Web developers may consider implementing HTTPS if they want to show support for HTTPS Everywhere, want to take advantage of SEO bonuses that Google introduced in mid-2014, want to use new web platform features such as Service Workers that are available only in secure contexts, or just care about their users' credentials not getting stolen. The EFF has answered some common objections to implementing HTTPS by giving tips on how to reduce connection overhead[2] but has not yet given guidance to implement HTTPS on small sites such as blogs, forums, and wikis. The expensive part of implementing HTTPS used to be the TLS certificate from a commercial certificate authority, used to detect the presence of a man in the middle.[3][4] But that's no longer much of an obstacle since StartCom and WoSign started offering free certificates for a domain, and especially in the fourth quarter of 2015 when Let's Encrypt went live. This makes some people wonder[5] why web sites use unencrypted HTTP at all nowadays. But even with free certificates for personal sites, implementing HTTPS on a site that doesn't make money is not without its tradeoffs.
You may discover that your site depends on third-party services unavailable through HTTPS. For example, Google AdSense did not support HTTPS[6] until September 2013,[7] and those ad networks that do support HTTPS may pay noticeably less for each HTTPS impression.[8] In 2013, switching to HTTPS cut dolphin-emu.org's ad revenue roughly in half.[1] The reluctance of ad exchanges to go full HTTPS[9] is one of the things that held up migration of The Guardian to HTTPS until mid-2016.[10] Or a database of browser support for web features may not support HTTPS. Placing such a widget on a page may result in warnings about "mixed content" on a page, or insecurely delivered objects that may be able to change the behavior of securely delivered objects, and some browsers present this warning as a modal alert box, disrupting the user's experience in much the same way that a pop-up does. Web site operators who depend on income from an ad network that does not support HTTPS may have to redirect anonymous visitors from HTTPS to HTTP in order to show advertisements to these viewers without the pop-up.
The other problem with a small public site is the periodic manual work to keep the site's certificate renewed. Unlike renewing a domain and web hosting, renewing a certificate requires manual steps every year if a site's hosting provider doesn't support Let's Encrypt. Some users have tried to passive-aggressively work around this by creating a Ruby script to automatically open a support ticket to get a renewed cert installed. Or if you don't want to go through the manual dance of renewing every few months, especially on hosting environments that make certificate installation hard to automate, SSLs.com offers a 3-year Comodo certificate for $15.
TLS used to need a separate IP address for each certificate. This is no longer true since April 2014 because all supported web browsers can use Server Name Indication. So if you choose shared web hosting, make sure it offers TLS with SNI.
| Historical |
|---|
|
Before 2014 or so, many shared web hosts didn't offer HTTPS because many users' browsers did not support Server Name Indication (SNI), which allows name-based virtual hosting for TLS sites. SNI allows serving a different certificate to each hostname on a given IP address; without it, a browser sees only the primary certificate on port 443 of that address. In mid-2013, one in ten page views came from an SNI-ignorant browser, particularly Internet Explorer on Windows XP,[11][12] though this declined to fewer than one in forty by mid-2015.[13] Likewise, client-side applications written in Python were affected by Python 2's lack of support SNI until the release of Python 3.3 in September 2012.[14] Lack of SNI support, ostensibly to reduce hosts' support costs,[15] was noticed soon after the release of HTTPS Everywhere[16] and recognized as the major HTTPS barrier on sites without third-party mixed content.[17] To offer TLS to these viewers, you need a dedicated IPv4 address in order to make your site's certificate primary on the IP. By 2006, the annual cost of a dedicated IPv4 address from a web hosting company had already exceeded the annual cost of a certificate,[18] and these addresses have become even more scarce since then. But operating systems that no longer receive security updates[19] can be presumed vulnerable to automatic installation of a keylogger or other man-in-the-browser attacks. Because no secure channel will protect communications to a compromised endpoint, you can feel justified in not serving these laggard users. |
Another barrier to TLS use that affects only private sites is the lack of PKI for the .local domain used by DNS Service Discovery (DNS-SD), as CAs cannot issue certificates for sites not reachable over the Internet.
No PKI means present browsers will present certificate errors for DNS-SD sites.
This makes it impossible for a site discovered through DNS-SD to offer a Service Worker or other new web features that work only in secure contexts unless the browser lets the user import a device's self-signed certificate using NFC or QR codes or similar, as suggested in the minutes of an October 2015 meeting about TLS on IoT devices.
Thus it would cause a problem for someone whose portfolio includes the source code of an application intended to run on a home server reachable only within the home network.
While you're at it, try to find a hosting provider that offers PostgreSQL if you can. Some people have reported problems with the fundamental design of PHP and MySQL or with the default settings of PHP and MySQL that a lot of popular web applications rely on. And a disturbing number of shared web hosts don't offer any language but PHP on their cheapest plans, and they don't offer PostgreSQL on anything below a virtual private server (VPS). Even what they do offer may be a years-old outdated version because an upgrade could break other customers' existing sites hosted on the same server that depend on deprecated features, and shared hosts don't always make it easy to move an account to a new server with new versions of the language and database.
Some Internet service providers in some countries allow running a server at home. This gives control comparable to a virtual private server but requires you to leave a PC turned on at all times, and it may need to send periodic messages to the DNS provider to update your home computer's IP address.
There are three drawbacks. First, it doesn't work in all countries. ISPs in some countries without a large allocation of IPv4 addresses put all customers behind a transparent HTTP proxy or a big NAT, where one public IP address represents hundreds or thousands of customers. Use of a carrier-grade NAT was reported as early as 2005.[20] Second, check your acceptable use policy: some ISPs consider running a server on a home SLA as grounds for disconnection, and some enforce it by blocking inbound ports or the HTTP or TLS handshake. Third, leaving a computer powered on takes electric power and causes heat and noise unless you host it on a cheap, passively cooled device like this $25 USB stick or a Raspberry Pi board.
Type budget ssl hosting into Google and you might be able to find plans under $120 per year.
Most of these will be similar to the HTTP-only shared hosting that you may have used in the past.
Most are SNI-based instead of name-based so that each site can have its own SSL certificate.
A few use a certificate owned by the hosting company that lists multiple sites in Subject Alternative Name fields.
However, shared hosting is less likely to support the Let's Encrypt certificate authority.
Past searches have returned results like the following:
Some hosts offer a virtual private server (VPS), also called a virtual dedicated server (VDS), for $120 per year or less. A VPS is a virtual machine, run on a server in a datacenter. The customer has privileges equivalent to those of the administrator of a dedicated server, including the ability to customize the operating system. A VPS is far more likely to have its own public IP address than a shared hosting account, allowing it to run several HTTPS sites on separate ports, or even several HTTPS sites on the standard port 443 for those visitors whose browser supports SNI. The 2010s brought plenty of competition in this so-called "cloud" space.
You might try designing your web application to use OpenID so that your site never sees passwords. Users would log in with their AOL, Google, LiveJournal, Ubuntu One, WordPress.com, or Yahoo! account, and these well-known identity providers would take care of all the SSL. But then you'd have the same problem as web sites that run only their login page through HTTPS and immediately drop back to HTTP: though the password is encrypted, the session cookie is not, and that can still be sniffed and cloned. And now that OpenID Connect has replaced OpenID 2.0, other practical problems with OpenID Connect complicate this.
So design your application to be completely stateless or otherwise anonymous. All information submitted to the site is either immediately visible to the public, without any form of authentication or authorization, or deleted after the page finishes loading. This can work for applications where you are demonstrating only the client side, such as graphic design of CSS, or a game written in JavaScript that saves its state to the local storage. Such a fully static site can be stored in Simple Storage Service (S3) by Amazon Web Services.
One Slashdot user suggests[39] that anyone seeking a web development position ought to have developed a bank interest/mortgage/retirement calculator written in PHP, Perl, Python, Java, Ruby, etc. that calculates on the server, one written in JavaScript that calculates on the client, a video game written in JavaScript or Flash, a news aggregator that combines a fixed set of Atom feeds, and an anonymous imageboard with a spam filter. Another recommends a regex tester or a currency converter.[40] They appear to claim that web applications can be made sticky even without storing preferences in a user account or session cookie.
Another option is to provide a stand-alone program designed for PCs running Windows (.msi), PCs running GNU/Linux (.deb), or Android-powered devices (.apk).
Since 2011, Android phones have been available on prepaid carriers, and both the Nexus 7 by ASUS and the Kindle Fire by Amazon are affordable Android tablets.
Stick with HTTP-only shared hosting at any entry-level provider that doesn't completely suck,[41] but put prominent warnings on the site that the connection is not secure because this is a demonstration site, and that users should not submit any valuable information or use the same password as on other sites. This will provide evidence of web application programming ability,[42] even if it is not as valuable to an interviewer as the experience of having run a production web site.
Pin Eight has chosen to combine shared hosting with SNI with this approach. Users logging in insecurely are presented with a warning and given an option to switch to HTTPS, followed by a disclaimer about IE on XP.
.py extensions. Until Python 3.3 implemented its own shebang line processor per PEP 397, Python had no way to determine whether a double-clicked .py file was written in Python 2 or 3, which held back adoption of Python 3. Python 3.3 was the first to allow coexistence of Python 2 and 3 on Windows.
Categories: Computer security