Security

Over the years, there has been many attacks and compromises of various networks, some of these are from internal attacks, others are from external agents.  Many of these attacks are in the form of attempting to gain access to an account with high enough access to give them privileges to gain access to services they require for their purposes.  In the case of Sony they were after their internal data.  In these cases the enemy agents, their main goal is to gain an account with Administrative priviledges, because these accounts give unfettered access to not just a single system but multiple system, and all the data on those systems.  These may include, but not limited to the workstations, servers, file servers.  And in the case of Windows based systems, this could give access to even Workstations and Servers that are encrypted with Microsoft's Encrypted File System.  This single all powerful account permission, gives a single attack target, and with this ability being remotely accessible it makes this an ideal target.  This account alone can not only gain access to the important information, but in some cases even hide the existance of the attack. 

So how could this be fixed?  People may believe that this cannot be fixed, but this risk can be greatly reduced, since many attacks that are not from "inside threats", occur through phishing attacks, the simplest method is to simply seperate the users account from their administration accounts, with this change it makes it more difficult from providing unfettered access.  An added level of security would to provide seperate machines for administration and day to day usage, this limits the attack plane.  But either method, requires that these administrative accounts should have the least level permissions to do their job.

A better solution though it would require a great deal more configuration, and possibly functional changes with the various operating systems, is to build a system based on Privilege seperation, each administrative account will have limited access, and cannot view or access functions outside of it's mandate.  So a user administration account, could manipulate the users account information, and provide privilege access to below this accounts privilege levels of this account, but would not have access to the file system.  The filesystem administration account would be totally unaware of detailed user information, and could not modify or user information, and would not have access to the account passwords.  Services administrator account, would give access to required file, network, and other services required to start and run the service.  The main Administrator account can only modify, create, delete the privilege administrator accounts.

Priviledge seperation would provide, a greater level of security by limiting what an administrator account can do, especially if the true administrator account is only accessible from a trusted interface, this would completely limit what can be done by any of the administrator accounts, and almost completely limit unauthorized accounts or accounts receiving unauthorized permissions.

Problem

SSL and TLS standards all have a major weakness, trust is linear.  The certificate your server is signed by one organization, that certificate is either signed by one of their own keys, or by the the key for the same certificate.  This can lead to one of the security risks if someone can compromise or falsify one of the signing keys of the trust relationships. Once this trust relationship is compromised, the attacker may use this for countless actions.

Currently on SSLabs this site has an A+ Rating, but with this rating the level of support for older web browsers has been reduced.

As of this change, IE on XP is not supported, but you should be updating XP anyways.

SSL2 and SSL3 has been fully disabled.  TLS1.0 is on my list to disable

So OpenSSL has released their Project Roadmap, to many this seems to be a push in the right direction after many notable vulnerabilities in the past, which has caused at least to forks to be created. 

I have noted in the past, many issues with the OpenSSL code base, which has finally been brought to light, these consist of a constantly changing API, poor or non-existant documentation, complexity of the code, readability of the code, and the shear number of versions.

Changing API

The API in a release should never change, for any version of 0.9.8*, they API should be unchanging.  Once the version has been released no new features should be added, only security fixes.  This reduced the headache of refactoring code when some major change has occurred.  API Changes should occur in phases as well, with deprecation of previous functions occuring over a long period, this would allow for updating to newer major versions with little impact to the third party code.

Poor or Non-Existant Documentation

This is a pretty annoying issue.  There is little in the way of useful documentation, this is more of a problem for new users to using OpenSSL,  many of these questions aren't answered on the OpenSSL site at all, but are elsewhere, on potentially less reliable or trusted sites.  Now some of the questions have been answered, but still not in such a way that a lay-person could easily understand what they are doing, why they are doing it, or the potential risks?  These are such questions

• How to create a self-signed certificate?
• How to generate an SSL Key?
• How to generate an SSL Certificate Request?
• How to revoke an SSL Certificate, or Key?
• How to remove the passphrase from a Key?
• Descriptions of each encryption, random number generation, and hashing methods, and the pro's and con's of each.
• As a developer, How to use each function?  (This can also have a wrapper to simplify development, by having 1 or 2 functions that do the required steps for the developer, this means that common security mistakes can be avoided, for the less advanced)

These are all very important questions, and not always covered by the developer, but often through third party sources.  Mind you, I have noticed more information cropping up in recent months and years.  For functional documentation, the POD files generated should be on the website, and documented inline, if it isn't already.

Complexity of the Code 

The OpenSSL code is notoriously, complex to browse through with the multitude of files.  Many things should be done to simplify the code tree.

• Group together similar items in the source.
  • Encryption routines
  • Hashing routines
  • Formatting routines
  • Configuration routines
  • Platform Specific code (for adding missing functions from a platform, or Assembler code)
  • Applications
• Abstract functions to allow for a single code base to support multiple platforms, don't ifdef the crap out of the code
• Standardize on coding practices
• Code reviews
• Internal and External Audits
• Modular coding style, this would then allow for functions/features to be stripped away, with very little change to the base code, such as delete a directory, and a single line change in the base code.
• Remove the external engines, as useful as it can be, this should be part of the OS, and if you are keeping them use them as a data source for RNG not as the RNG.

A major thing is that is missing that should be implemented would be

Number of Versions

This has always been a sticking point for me, there shouldn't be the number of versions on the go as OpenSSL currently has, this creates code complexity, as a change for one might have to be back ported and forward ported to the various releases, right now there's at least 5 in development if not more. 

• 0.9.8* series that dates back to 2005
• 1.0.0* series that dates back to 2010
• 1.0.1* series that dates back to 2012
• 1.0.2* series is in Beta
• 1.1.0* is in development
• Two FIPS modules for OpenSSL

Of these 0.9.8* should have been retired awhile ago. 1.0.0* should be in a stage of critical bug fixes.  1.0.1* should be fixes and usability improvements. 1.0.2* should be still changing, with creating wrappers for the new API to port the old code to using it. and 1.1.0* should be in API flux.