Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'm not going to go in depth on SSL in general, gregmac did a great job on that, see below ;-).</p> <p>However, some of the most common (and critical) mistakes made (not specifically PHP) with regards to use of SSL/TLS: </p> <ol> <li>Allowing HTTP when you should be enforcing HTTPS </li> <li>Retrieving some resources over HTTP from an HTTPS page (e.g. images, IFRAMEs, etc) </li> <li><p>Directing to HTTP page from HTTPS page unintentionally - note that this includes "fake" pages, such as "about:blank" (I've seen this used as IFRAME placeholders), this will needlessly and unpleasantly popup a warning.</p></li> <li><p>Web server configured to support old, unsecure versions of SSL (e.g. SSL v2 is common, yet horribly broken) (okay, this isn't exactly the programmer's issue, but sometimes noone else will handle it...)</p></li> <li><p>Web server configured to support unsecure cipher suites (I've seen NULL ciphers only in use, which basically provides absolutely NO encryption) (ditto)</p></li> <li><p>Self-signed certificates - prevents users from verifying the site's identity.</p></li> <li><p>Requesting the user's credentials from an HTTP page, even if submitting to an HTTPS page. Again, this prevents a user from validating the server's identity BEFORE giving it his password... Even if the password is transmitted encrypted, the user has no way of knowing if he's on a bogus site - or even if it WILL be encrypted.</p></li> <li><p>Non-secure cookie - security-related cookies (such as sessionId, authentication token, access token, etc.) <strong>MUST</strong> be set with the "secure" attribute set. This is important! If it's not set to secure, the security cookie, e.g. SessionId, can be transmitted over HTTP (!) - and attackers can ensure this will happen - and thus allowing session hijacking etc. While you're at it (tho this is not directly related), set the HttpOnly attribute on your cookies, too (helps mitigate some XSS).</p></li> <li><p>Overly permissive certificates - say you have several subdomains, but not all of them are at the same trust level. For instance, you have www.yourdomain.com, dowload.yourdomain.com, and publicaccess.yourdomain.com. So you might think about going with a wildcard certificate.... BUT you also have secure.yourdomain.com, or finance.yourdomain.com - even on a different server. publicaccess.yourdomain.com will then be able to impersonate secure.yourdomain.com.... While there may be instances where this is okay, usually you'd want some separation of privileges...</p></li> </ol> <p>That's all I can remember right now, might re-edit it later...</p> <p>As far as when is it a BAD idea to use SSL/TLS - if you have public information which is NOT intended for a specific audience (either a single user or registered members), AND you're not particular about them retrieving it specifically from the proper source (e.g. stock ticker values MUST come from an authenticated source...) - then there is no real reason to incur the overhead (and not just performance... dev/test/cert/etc).</p> <p>However, if you have shared resources (e.g. same server) between your site and another MORE SENSITIVE site, then the more sensitive site should be setting the rules here. </p> <p>Also, passwords (and other credentials), credit card info, etc should ALWAYS be over SSL/TLS.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload