Wednesday Aug 05, 2015

Strengthening Signatures

Later this year, the Oracle JDK team plans to restricting the use of MD5 signatures within X.509 certificates used by SSL/TLS and code-signing. This will take place in the public versions of JDK 9 (early access) and JDK 8, as well as the commercially supported JDK 7.

The IETF has recommended a move away from MD5 since 2011.

Most Certificate Authorities followed this guidance by requiring stronger signatures (typically in the SHA family). Although the default JDK options switched away from MD5 in the past, additional time was necessary for organizations to phase out their use of MD5 and reissue certificates with stronger hash algorithms.

System Administrators that still actively use certificates with MD5 hashes should consider revoking and/or re-issuing those certificates with stronger signatures. Developers that have previously signed artifacts with MD5 signatures should consider re-signing and timestamping these artifacts.

This change will only affect MD5 usage in regards to certificates. This will not affect other uses, such as MD5 hashing of files to generate checksums or perform simple checks.

System Administrators can control algorithm availability by adjusting their JRE configuration. For example, some organizations may still rely on internal systems that require MD5. Users of these systems will likely see a message "constraints check failed: MD5withRSA" in their application logs.

This configuration change takes place within the jre/lib/security/ file. The specific property is jdk.certpath.disabledAlgorithms.

Thursday Dec 11, 2014

That's so SecureRandom

Random numbers are an important part of software systems, especially those that deal with security or encryption. The Java platform offers different types of randomness based on intent, and static typing can further guide that choice for library developers.

This post is intended to explain how the Oracle JDK provides random numbers, to guide their usage:

  • Developers building Java software, to use the right randomness in the right place.
  • Companies buying or running Java software to understand how to evaluate or control that software.
  • System Administrators tuning the security and performance of those systems, understanding why/where/how to make adjustments.

Randomness in the JDK

Java SE provides three mechanisms for generating random numbers based on their usage:

  1. A fast Random number designed for basic tasks where true randomness is not the main goal. This is useful for things like which shade of color to use, preventing overlap in force-directed layouts, or which picture to show from a list after evaluating demographic information.
  2. High-concurrency programs may also use ThreadLocalRandom if they value speed over true randomness. This is the same as above but will likely give better performance if simultaneous threads generate pseudo-random numbers at the same time.
  3. A slower but more random SecureRandom designed for important tasks where the inability to predict numbers is crucial to success. Examples include cases like gambling, scientific sampling, or any cryptographic operations. Although slower than the other two random number generators, its better randomness in many applications.

Having these choices allows developers to make the appropriate decision based on their application.

The Java Platform also allows software operators to override and control this behavior. For example improving true-ness of the Random generator or improving speed of SecureRandom with dedicated hardware.

Security through static typing

Java’s static typing can also enforce that program authors and library users apply the proper Random implementation. The random classes are designed with inheritance, allowing full interoperability across implementations. Both SecureRandom and ThreadLocalRandom inherit from Random, which means that implementations can be swapped or specified:

Random pseudoRandom = new Random();
Random pseudoRandomConcurrent = ThreadLocalRandom.current();
Random secureRandom = new SecureRandom();

For API design, developers can choose to only accept the appropriate version based on their use case. Given that true randomness is crucial to the success of cryptographic operations, it is critical that cryptographic APIs only accept SecureRandom arguments and never the super-class of Random. One example of this is KeyPairGenerator, which helps generate public/private keys that are used by many cryptographic systems. Users can only seed this with true-random values and not pseudo-random values.

KeyPairGenerator.initialize(int keysize, SecureRandom random);

Developers can only call this method by using statically-typed SecureRandom values. The super-type Random PRNG, which might make predictable keys, cannot work. Calling the overloaded KeyPairGenerator.initialize(int keysize) will also use a SecureRandom and is fine, the point here is that static typing prevents other types of Random from being used.

Using the previous example, one could call:

kpg.initialize(4096, (SecureRandom) secureRandom);

Or by specific static typing:

SecureRandom staticEnforcement = new SecureRandom();
kpg.initialize(4096, staticEnforcement);

API designers building secure systems should follow this example of statically typing SecureRandom in method signatures. When vetting secure software, look for usage of Random where a SecureRandom might be more appropriate. The US CERT Java coding guidelines offer additional guidance on evaluating the use of random numbers. Simon Kitching also has a good write-up about Using the SecureRandom Class.

Sources of Randomness

The sources for randomness are listed in the JDK’s security Standard Names documentation, identifying which are blocking or non-blocking. Although some sources rely on entropy pools, SecureRandoms like SHA1PRNG are quite fast once seeded and do not need additional entropy.

Blocking is especially important on Linux systems, where some calls to /dev/random may pause while the system generates a new true-random number. There is a trade-off /dev/urandom device that is non-blocking but somewhat less random.

Within a Java installation, the administrator can adjust various settings through the "JRE/lib/security/" configuration file. That file contains documentation about configuring securerandom.source and securerandom.strongAlgorithms. On Linux systems, the administrator may set their securerandom.source to  /dev/random or /dev/urandom accordingly.

Each operating system contains its recommended default value. System Administrators may edit that value, for example if their system has different RNGs or if they have a separate specialized hardware RNG.

JavaMex has a page describing the sources of entropy that Java uses on different operating systems.

Additional information is available in the SecureRandom javadoc.

Tuesday Aug 19, 2014

New Management Console in Java SE Advanced 8u20

Java SE 8 update 20 is a new feature release designed to provide desktop administrators with better control of their managed systems. The release notes for 8u20 are available from the public JDK release notes page. This release is not a Critical Patch Update (CPU).

I would like to call attention to two noteworthy features of Oracle Java SE Advanced, the commercially supported version of Java SE for enterprises that require both support and specialized tools.

  • The new Advanced Management Console provides a way to monitor and understand client systems at scale. It allows organizations to track usage and more easily create and manage client configuration like Deployment Rule Sets (DRS). DRS can control execution of tracked applications as well as specify compatibility of which application should use which Java SE installation.
  • The new MSI Installer integrates into various desktop management tools, making it easier to customize and roll out different Java SE versions.

Advanced Management Console (product page)

The Advanced Management Console is part of Java SE Advanced designed for desktop administrators, whose users need to run many different Java applications. It provides usage tracking for those Applet & Web Start applications to help identify them for guided DRS creation. DRS can then be verified against the tracked data, to ensure that end-users can run their application against the appropriate Java version with no prompts.

Usage tracking also has a different definition for Java SE than it does for most software applications. Unlike most applications where usage can be determined by a simple run-count, Java is a platform used for launching other applications. This means that usage tracking must answer both "how often is this Java SE version used" and "what applications are launched by it."

Usage Tracking

One piece of Java SE Advanced is a centralized usage tracker. Simply placing a properties file on the client informs systems to report information to this usage tracker, so that the desktop administrator can better understand usage. Information is sent via UDP to prevent any delay on the client.

The usage tracking server resides at a central location on the intranet to collect information from those clients. The information is stored in a normalized database for performance, meaning that a single usage tracker can handle a large number of clients.

Guided Deployment Rule Sets

Deployment Rule Sets were introduced in Java 7 update 40 (September 2013) in order to help administrators control security prompts and guide compatibility. A previous post, Deployment Rule Sets by Example, explains how to configure a rule set so that most applications run against the most secure version but a specific applet may run against the Java version that was current several years ago.

There are a different set of questions that can be asked by a desktop administrator in a large or distributed firm:

  • Where are the Java RIAs that our users need?
  • Which RIA needs which Java version?
  • Which users need which Java versions?
  • How do I verify these answers once I have them?

The guided deployment rule set creation uses usage tracker data to identify applications both by certificate hash and location.

After creating the rules, a comparison tool exists to verify them against the tracked data: If you intend to run an RIA, is it green? If something specific should be blocked, is it red? This makes user-testing easier.

Check if the rule is right

MSI Installer

The Windows Installer format (MSI) provides a number of benefits for desktop administrators that customize or manage software at scale. Unlike the basic installer that most users obtain from or OTN, this installer is built around customization and integration with various desktop management products like SCCM.

Desktop administrators using the MSI installer can use every feature provided by the format, such as silent installs/upgrades, low-privileged installations, or self-repair capabilities

Customers looking for Java SE Advanced can download the MSI installer through their My Oracle Support (MOS) account.

Java SE Advanced

The new features in Java SE Advanced make it easier for desktop administrators to identify and control client installations at scale. Administrators at organizations that want either the tools or associated commercial support should consider Java SE Advanced.

Thursday May 01, 2014

Deployment Rule Set by Example

Recently I encountered a situation whereby a System Administrator needed to adjust thieir systems to run a specific RIA on an older version of Java. By using Deployment Rule Sets, we were able to achieve the desired outcome. The specific RIA ran using the older version of Java with no prompts to the end users, while all other RIA applications used the latest, most secure version of Java.

This post is intended for System Administrators managing a white list within an organization.

Assessing the environment

In this particular case, the RIA itself was designed to run on Java 6 update 31 (released in February 2012, but public updates for Java SE 6 ended in February 2013). That also means that it does not adhere to the security requirements introduced in a recent Java SE 7 Critical Patch Update. Because this RIA was known to be safe and necessary for business operations, the goal was to be able to execute it with no prompts.

Installing multiple versions of Java

When delegating RIAs to use older Java versions, it is necessary to have at least two installations available:

  1. The latest Java version, which will be used by default except in cases where you configure it to delegate to the older version. We installed this as the default patch-in-place.
  2. The specific older versions needed by the RIA, which will only be accessible through your Deployment Rule Set. We installed this as a static installation to prevent any interference in case that a different Java SE 6 version had to be installed for something else.
    1. Although older versions are not updated with the latest security patches and not recommended for use in production, the Deployment Rule Set mitigates the definition of "in production" because the older JRE is only accessible from explicitly whitelisted areas.

Information about these installation types can be found within a previous post, Managing Multiple Java Versions. Comprehensive documentation is provided by Oracle about silent installation switches for package management as well as disabling third-party sponsors.

Once items were installed, we had two noteworthy locations on the Windows desktops (others may be available as well, but these are the important ones):

  1. C:\Program Files\Java\jre7
  2. C:\Program Files\Java\jre1.6.0_31

Creating the Deployment Rule Set

Instructions on creating a Deployment Rule Set are available in the post Introducing Deployment Rule Sets or in the complete Deployment Rule Set documentation.

The actual deployment rule set used looks like:

<!-- Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.
  See -->
<ruleset version="1.0+">
        <id location="" />
        <action permission="run" version="SECURE" />
        <id location="" />
        <action permission="run" version="1.6.0_31" />

In this example, we were able to identify and test each item. For example, the first rule checks that users could run the normal detection applet without any prompts. That demonstrated the correct setup of the DRS. Once successfully set up, the second rule allowed us to target their application.

Ensure the DeploymentRuleSet.jar is signed correctly for each Java installation

Most certificates from Certificate Authorities should work out of the box. The certificate used to sign your Deployment Rule Set must be trusted by each Java installation.

After your Deployment Rule Set is in place (in the documented area), the easiest way to check is to look at the control panel. Instructions for checking this are in the previous post, Introducing Deployment Rule Sets, under the “Verify usage of your rule set on a client desktop.”

Importing certificates into the older Java version

Although most administrators do not need this step, sometimes the older JRE does not contain the newer root certificate. In that case, it is necessary to locate the CA’s root certificate and explicitly import it:

"C:\Program Files\Java\jre1.6.0_31\bin\keytool" -importcert -keystore "C:\Program Files\Java\jre1.6.0_31\lib\security\cacerts" -alias AuthNameNoSpaces -file TheRootTheyProvided.cer

Once we had the root’s certificate inside both keystores, the RIA launched correctly on the older Java 6.

Verifying "is this working right"

Testing your Rule Set involves opening the RIA and verifying execution. Other system tools will help check and verify any assumptions. In addition to launching RIAs like the detection applet, the regular Task Manager will help understand which versions are getting launched.

Within the basic Task Manager, the Processes tab can show a command line column. In the case that you are launching a different version, you can show the Command Line column. In this screenshot, I’ve shrunk the view but it’s easy to see what I am running.

Screenshot of command-line in Win7 task manager

There are other tools available to view a process chain as well, where you will see a chain that looks like:

  • iexplorer.exe
    • jp2launcher.exe
      • java.exe (from the default JRE installation area)
        • java.exe (from your targeted JRE usage area)

Automating Package Installation

Once the item was identified as working, we were able to integrate the previous silent installation switches to roll the installations out onto different computers.

Most users or members of staff can run basic installers or scripts as needed. Large enterprises with desktop management systems often combine silent installation switches and customization commands (like the keytool import) with MSI creators, and then roll a single file out for installation.

I will refrain from discussing package creation and roll-out in detail. Use the right mechanism that works within your organization.

Reminder about external distribution

The Deployment Rule Set feature is intended for organizations to manage their own configurations. It is not meant as a way to simply "whitelist everything just so warning dialogs go away," "force everyone to never update," or "external users please download this file onto your system to use this application." By default, specifying the version="SECURE" attribute is best unless you know specific reasons restricting compatibility to a specific JRE version.

Publicly distributed Deployment Rule Sets found to contain insecure "whitelist everything" configurations may have their signing certificate blacklisted from future use of Deployment Rule Sets.

Additional Helpful Information

Appendix: Debugging if things to not work as expected

System Administrators new to Java may find the Java console useful to understand what is happening. Most users neither turn on nor see this console.

By turning the console on in the Java control panel, we were able to see execution.

Screenshot of java console

The first line in that file indicates the current version in use: JRE 1.8.0-b132. This is clearly not 1.6.0_31, meaning that it matches the first rule.

When we began using the Deployment Rule Set that delegated to Java 6 update 31, two major things happened:

  1. In the Task Manager process tree, two Java processes appeared. The first was the latest Java, the second was the older version connected to this process.
  2. Because we had the Java console turned on, two consoles appeared: one for each version.

If you press ‘5’ on that console, it will output a significant amount of log information. I won’t paste a sample log here because they can get long, but the really interesting parts look like:

 Sample from log
What it tells us
 Using JRE version 1.8.0-b132 Java HotSpot(TM) 64-Bit Server VM  At the top, this tells us which version is currently in use.
 Lines beginning with “ruleset:”
ruleset: RuleSetParser.parse() returning 2 rules:
 These tell what is happening with the DRS, isolated from other information.
 Lines that talk about “ruleset” and “location”
ruleset: finding Deployment Rule Set for
        title: Java Uninstall Applet
        jar location:
        jar version: null
        isArtifact: true

 The location information helps me understand if I told the ruleset to whitelist the right place.
Sometimes, though not often, the browser URL and actual application URL are different.
In the example to the left, both are on
Although my browser visits an area, /en/download/installed.jsp the actual files are hosted in /applet.
That means copying from my browser’s address bar would not have worked.

Appendix: Identifying applications by Certificate Hash or Location

The two primary ways of creating a deployment rule are by location or certificate hash.

  • Certificate hashes help identify a publisher. For example I could automatically run Oracle RIAs by creating a rule to run RIAs whose certificate hash is 794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6.
    This rule would take effect regardless of where the RIA was hosted.
  • Location identifies where the RIA (specifically its JAR files) is hosted. This is sometimes easier to copy from a browser’s address bar and can be used in cases where the RIA publisher did not actually sign the RIA.

If the RIA uses LiveConnect (javascript integration), you must create a Location rule to whitelist the hosting domain and accept the LiveConnect calls.

Within the Java Console, there are also ways to locate both of those identifiers.

  • security: SHA-256Certificate finger print: Long certificate hash
  • basic: Plugin2ClassLoader.addURL parent called for

Those will help identify the items that the RIA plugin is seeing, so then you can look for one of the following messages:

  1. ruleset: Rule hash matches certificate hash (or a similar message about location)
  2. ruleset: no rule applies, returning Default Rule

Thursday Apr 17, 2014

Secure Coding Guidelines for Java SE

With so much happening around the Java platform, it’s understandable if you missed the recent improvements we made to the Secure Coding Guidelines for Java SE.  In January 2014 the Java Platform Group released a significant update, Java 7 Update 51 establishing code-signing as the default for Applets and Web Start applications.  Following in March 2014, we hit another major milestone with the long anticipated release of Java SE 8.

There are a number of improvements to the Secure Coding Guidelines for Java SE.  On the surface, the larger domains of the coding guidelines like Fundamentals and Denial of Service are the same but content has been improved throughout each domain based upon changes to Java’s threat landscape.  Likewise, small but noteworthy improvements to content navigation were made to the domains in table of contents facilitating quick navigation for readers.

Beyond content improvements, code examples were refreshed to highlight new Java 8 features like Lambda.  While our coding guidelines are updated for Java SE 8, most guidance is relevant to older versions like Java SE 7.  Please keep in mind secure application coding and design is only one component in a secure solution.  Building secure solutions requires OS security hardening, application and infrastructure hardening, patching all components on a timely schedule, etc.  More information about Java security is available in the Security Resource Center for Java.

Monday Apr 07, 2014

JavaOne 2014 Security Track Early Acceptance Sessions

J1 LogoJavaOne 2014 is Oracle's flagship software developers conference event for Java.  Security has been a focus at the conference for many years but last year Oracle brought security to the forefront by including it as a track.  If you have ideals for interesting Java security sessions we would be delighted to review them.  The JavaOne CFP is open until April 14, 2014.

 Back to the security track, each year the tracks highlight their early acceptance sessions to build momentum for the conference.  This year I would like to highlight the following early acceptance sessions for the security track and show a little of what we are planning.  

CON2120 Anatomy of Another Java Zero-Day Exploit

Presenter:  David Svoboda, Software Security Engineer, Carnegie Mellon

Abstract:  Java was recently hit by several major exploits. These exploits were written in pure Java and relied on several obscure components of the Java library. Understanding how exploits undermine Java security is a fundamental step in understanding and improving Java security and producing secure Java code. Consequently, this session demonstrates and examines a public exploit. It dissects the code of the exploit and illustrates how the exploit managed to attack an unpatched Java Virtual Machine, focusing on the techniques the exploit used, with references to relevant guidelines from the CERT Oracle Secure Coding Standard for Java. The session concludes with an explanation of how Java was patched to defeat the exploit.

CON1713 Leveraging Open Source for Secure Java Website Construction

Presenter:  Jim Manico, Secure Coding Instructor, Manicode Security (JavaOne Rock Star)

Abstract:  The need to master the skills required to build secure Java web and webservice applications gets stronger every day. There is help for you in the world of opens source! Do not build your own web application security controls from scratch! This presentation describes the use of several Oracle, OWASP, Apache and Google open source Java projects that are essential tools for constructing a secure web application.

In addition to community speakers, we will have Oracle experts from the Java security team to discuss new security features and improvements like the recent release of Java SE 8.  See you at JavaOne!

Tuesday Apr 01, 2014

Java 8's new Type Annotations

Java 8 introduces two important changes to Annotations designed to help developers produce better code and improve the accuracy of automated code analysis to verify that quality.

Quick Annotations Webinar

There is a great video explaining the new improvements in the Java 8 Launch Webinars called “Enhanced Metadata - Annotations and Access to Parameter Names” by Alex Buckley and Michael Ernst.

Annotation Improvements

Type Annotations allow developers to write annotations in more places than before. The compiler can then verify these annotations, for example identifying uses of null values, accidental value modifications, and cases where data crosses a trust boundary without proper validation. By moving some annotatable information from the Javadoc (understood only by people) and into the code (understood by both people and analyzers), it is easier to understand intent and verify the absence of certain errors.

Repeating Annotations make it easier for authors of these annotations because there is less need for wrapper annotations.

The Checker Framework provides a few Type Annotations that could benefit both library and application developers, such as:

  • @NonNull – The compiler can determine cases where a code path might receive a null value, without ever having to debug a NullPointerException.
  • @ReadOnly – The compiler will flag any attempt to change the object.  This is similar to Collections.unmodifiableList, but more general and verified at compile time.
  • @Regex – Provides compile-time verification that a String intended to be used as a regular expression is a properly formatted regular expression.
  • @Tainted and @Untainted – Identity types of data that should not be used together, such as remote user input being used in system commands, or sensitive information in log streams.
  • @m – Units of measure ensures that numbers used for measuring objects are used and compared correctly, or have undergone the proper unit conversion.

Putting Type Annotations on your code

Java SE 8 allows type annotations anywhere that a type is used. Previously, annotations were only allowed on definitions. Some examples of this are:

Annotation Example Meaning
@NonNull List<String>
A non-null list of Strings.
List<@NonNull String>
A list of non-null Strings.
@Regex String validation = "(Java|JDK) [7,8]"
Check at compile time that this String is a valid regular expression.
private String getInput(String parameterName){
final String retval = @Tainted request.getParameter(parameterName);
  return retval;
The object assigned to retval is tainted and not for use in sensitive operations.
private void runCommand(@Untainted String… commands){
ProcessBuilder processBuilder = new ProcessBuilder(command);
  Process process = processBuilder.start();
Each command must be untainted. For example, the previously tainted String must be validated before being passed in here.

For reading annotations, the way to look at them is that they annotate the next item after that isn’t also an annotation.

Automating issue detection

When working on software, it helps to uncover potential problems early. A problem caught early is easier to fix than one caught later, and a potential problem caught right away is easier still. Some annotations allow problems to be caught immediately. The @Override annotation allows the compiler (or a static analysis tool) to immediately determine if a developer wrote the wrong method signature.

Other annotations, like @NonNull and @Readonly can be used by analyzers like the Checker Framework, FindBugs, Eclipse, NetBeans, IntelliJ, or a commercial analyzer. Those analyzers can then be run at compile time, through IDE background compilation, Ant/Maven, or continuous integration.

Type Annotations tell those analyzers what to look for. Without the Type Annotations in place, these analyzers would still be able to locate null-usage and write-modifications but would not know that they are wrong. The result would then be false negatives (no issue reported) or false positives (incorrect issues reported).


Type Annotations can greatly benefit teams that are geographically distributed or contain many members. By placing Type Annotations inside the code and running automated checks before commits or during integration builds, team members can identify situations where one change inadvertently affects another.

Optional Type Annotations are not a substitute for runtime validation

Before Type Annotations, the primary location for describing things like nullability or ranges was in the javadoc. With Type annotations, this communication comes into the bytecode in a way for compile-time verification.

Your code should still perform runtime validation.

Annotation validation versus Business Validation

Type Annotations are best used with common forms of validation that relate to computer science. There are certain types of business validation that are not applicable.

Well-suited for Type Annotations
Likely not well-suited for Type Annotations
  • Null value checks.
  • Numeric range checks.
  • Basic type checks, such as regular expressions.
  • Assignments and updates (e.g. read-only)
  • Dataflow validation detection (e.g. have the incoming function arguments gone through the right validation functions)
  • This function cannot be executed outside certain hours or on government holidays.
  • Access to a feature requires a certain account-type.


Annotations in core Java

There is no set of default type annotations available out of the box in the Java SE 8 platform. All previous examples in this post used the Checker Framework. The Type Annotations in Java SE 8 focused on the ability to put annotations in the right areas to describe a program. A separate, currently inactive JSR-305 (not part of Java 8) exists for identifying what those annotations should be.

The Checker Framework currently uses Java Annotation Index Files to gain comparable support for the core Java runtime and targeted libraries, or previous Java versions like Java SE 7 or 6.

Removal of APT

JDK 8 also removes a legacy annotation processing tool, named apt. Few users should be affected by this change. This was done as part of JEP 117 because everything required for annotation processing appears in either javax.annotation.processing or javax.lang.model.

Tuesday Jan 28, 2014

JDK 8 will use TLS 1.2 as default

Transport Level Security (TLS) is designed to encrypt conversations between two parties and ensure that others can neither read nor modify the conversation. When combined with Certificate Authorities, a proper level of trust is established: we know who is on the other end of the conversation and that conversation is protected from eavesdropping/modification.

Support for TLS 1.2 first appeared in JDK 7 (2011). For compatibility reasons, it is enabled by default on server sockets but disabled on clients. Since that time, the industry has made considerable improvements to address interoperability and backwards compatibility.

We are setting JDK 8 to use TLS 1.2 as the default for two reasons:

  1. TLS is backwards-compatible. After upgrading the default to 1.2, systems using 1.1 and 1.0 will continue to function*.
    1. * Unless configured to use an algorithm that was removed for security reasons. Few systems are affected by this.
    2. For a complete description of TLS 1.2, please see RFC 5246.
    3. A quick summary of TLS/SSL differences is available from yaSSL.
  2. It strengthens the protection of internet communications against eavesdropping.

For those testing JDK 8 early access, this first occurred in build 122.

TLS is transparent to most users and developers. For those that would like more details, we will cover:

  • Threats and the role of encryption
  • Compatibility with the JDK and other systems
  • Understanding your TLS implementation
  • Other considerations for TLS

Threats and the role of encryption

With a new well-motivated IETF working group for encryption as well as wide industry support for TLS 1.2, the time is right to update system defaults.

Qualys SSL Labs has done great research in depicting a threat model for TLS. Their best practices in dealing with the TLS threat model (specifically "2.2 use secure protocols") support this move.

Compatibility with the JDK and other systems

TLS 1.2 is designed to be backwards-compatible as described in the RFC Appendix E (above). If a 1.2 client connects to a server running a lower version, the client will adjust. If a lower client connects to a server running 1.2, the server will adjust. Because of backwards-compatibility, clients supporting TLS 1.2 will receive improved communications and older clients will continue to function.
  • We added support for TLS 1.2 in JDK 7 (July 2011) although it was not the default. JDK 8 (March 2014) will use TLS 1.2 as the default.
  • OpenSSL added support for TLS 1.2 in version 1.0.1 (March 2012). Most Linux distributions and scripting languages use OpenSSL.
  • Microsoft supported TLS 1.2 in Windows 7. Internet Explorer and .NET follow accordingly. TLS 1.2 was first enabled by default in Internet Explorer 11 (October 2013).
  • Firefox turned TLS 1.2 on by default in version 27 (February 2014).
  • Chrome supported TLS 1.2 in version 29 (August 2013).
  • Etc.

Adoption statistics from the Trustworthy Internet's SSL Pulse show a sufficient number of internet-facing systems using TLS 1.2 and compatible ciphers.

Understanding your TLS implementation

Developers or System Administrators can test servers and clients through the Qualys SSL Labs (server or client) or a different How’s My SSL website.

System Administrators can view their system’s TLS implementation to monitor clients or disable specific TLS versions. For example some system administrators in highly sensitive businesses may want to disable older TLS versions from ever being used.

View your client’s version through a GUI

  1. Open the Java Control Panel
  2. Navigate to the Advanced tab.
  3. At the bottom, there is an “Advanced Security Settings.”
  4. Check or uncheck the "Use TLS X.Y" box.

On a server or without a GUI

  1. To set this for everything:
    1. Open the file, either user-level or system-level.
    2. Set the appropriate property
  2. To set for a specific application or script:
    1. Use the startup flag

Other Considerations for TLS

The InfoQ article, Keeping Your Secrets, covers additional information for developers looking to understand more about transport security and encryption. Outside the role of TLS protocol version, that article covers good techniques to safeguard information:

For System Administrators (or some Developers): Perfect Forward Secrecy can be used in Java TLS connections. Using Perfect Forward Secrecy protects past conversations: in the event that if keys are lost in the future, someone cannot decrypt past conversations. As is common with TLS implementations, Perfect Forward Secrecy is not enabled by default. Those that do want to use it can update their https.cipherSuites property. Common values for this property are:

  • Anything on the Algorithm Standard Name list that start with TLS (Transport Level Security) followed by a type of DHE (Diffie-Hellman Exchange).

Monday Nov 25, 2013

Upcoming Exception Site List in 7u51

Over the last year, many new security related features have been implemented. Many of those features have been related to browser plugins for applets and web start applications (RIAs). A number of end users and software vendors have asked for more ways to configure their environment and use of applications. 

The Exception Site List is a way for end-users to control their own application whitelist and continue using RIAs that could not be timely updated to follow previously announced security requirements. The Exception Site List provides a way to continue using a RIA but is not intended as a way to remove all warnings for the user. End-users will still see important prompts, but those prompts will no longer block.

Comparison to Deployment Rule Set

The introduction of the Exception Site List creates a second way for whitelisting RIAs and decreases requirements for system administrators.

 Exception Site List
Deployment Rule Set
 Introduced  Java 7 update 51 (January 2014)
Java 7 update 40 (September 2013)
 Intended for
 End-user System Administrator
 Formatted as
 Plain-text Signed JAR file
 If the two conflict with each-other
 Loses Wins

 For standard policy enforcement, some system administrators may lock down usage of the Exception Site List as they would with any other control panel setting.

Getting Early Access to the Exception Site List

Developers looking to test their applications in advance of 7u51 and use the Exception Site List can download early access of Java 7 update 60 over at the JDK 7 website. That website is the easiest way for developers to get early access of releases.

Adding a site to the Exception Site List

End-users can access the Exception Site List from the Java control panel.

  1. Use your browser to access the RIA that you normally use.
  2. Copy the URL from the address bar.
    Only choose directory paths ending in a / and not a filename.
    • Right:
    • Wrong:
  3. Open the Java control panel.
    • Windows/Mac - Open your system control panel or System Preferences and choose Java.
    • Linux/Solaris - Run the jcontrol command.
  4. Choose the Security tab.
  5. Click the "Manage Site List" button near the bottom.
  6. A new window will open.
    Screenshot of Exception Site List
  7. Click the Add button.
    Screenshot of adding an exception site
    • Right:
    • Wrong:
  8. Click OK. The window will close. You may see an additional prompt if you use an unencrypted protocol such as http or file. Choosing encrypted protocols defends against potential man-in-the-middle attacks.
  9. Back on the control panel, click OK to close it.
  10. Reload the web page on your browser to launch the RIA.

Files behind the Exception Site List

Update Jan 22: The Exception Site List is intended for end-users to create their own whitelist. If you are a System Administrator managing this across many machines, you will find the Deployment Rule Set much easier. Group Policy efforts are better used behind distributing a Deployment Rule Set. You can self-sign a DRS.

The Exception Site List is aimed towards end-users controlling their own Exception Site List.

The file controlling the Exception Site List is stored in the user’s deployment location as described in the deployment configuration. On my Windows 7 laptop, this location is C:\Users\ecostlow\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites

The format is one site per line.

Sample customer support note

As changes are introduced, technical support representatives are usually asked for details. We will be creating a technical support note that can be downloaded and tweaked to help communicate this change to your customers. It is essentially a trimmed down version of this blog post with a stronger How-To message.

Update on Jan 14 2014: Here are the end-user instructions for using the Exception Site List. Otherwise if you need something more customizable, here is a sample Exception Site List support note. This is a docx file but it may appear as a zip.

Friday Nov 15, 2013

Security Resource Center

We recently launched a new Java security resource center on the Oracle Technology Network.The goal of this page is to aggregate security-related information for members of the Java community based on their roles.

The resource center is not meant for specific technical features. Features are different and well covered in documentation sections like cryptography. The resource center focuses more towards "security is everyone's responsibility" in discussing how features and people work together.

One of the first items added to the security resource center is an RIA Checklist that developers and managers can use to accommodate previously announced changes in Java 7 update 51 (January 2014).

Tuesday Oct 15, 2013

What to do if your applet is blocked or warns of “mixed code”?

Recent security changes, including the October 7u45 critical patch update, for RIAs (Applets & Web Start applications) have affected several audiences in different ways. Other types of applications (such as back-end server applications, web applications, middleware, client-installed applications, and others) are unaffected by these changes.

Two notable changes are:

  1. Java 7 update 45 (October 2013) introduced changes to the LiveConnect model of JavaScript calling Java RIAs whereby additional warnings are raised in certain situations.
  2. In the future, Java 7 update 51 (January 2014) will introduce a code-signing requirement for RIAs.

Affected RIAs should be patched and updated immediately by their developers. Sometimes this is not feasible, such as cases of an application purchased from a vendor, an RIA is burned into device firmware, or the RIA has been in use for years and nobody knows the maintainer.  In those situations, System Administrators can take steps to adapt to these changes if they prefer not to be notified.

Option 1

System Administrators can follow the instructions for creating a Deployment Rule Set and create appropriate rules to whitelist the RIA and javascript domains:

  1. First, identify the location of JavaScript where your web pages will be calling in to Java. For example, by whitelisting your own domains and thereby disallowing alternate sources.
        <id location="" />
        <action permission="run" version="SECURE" />
    This is an important step because web pages are often made of many components, such as analytics, image hosts, and other pieces. Whitelisting your domain prohibits others from calling in to your Java application.
  2. If the RIA is hosted at a different location, such as a content delivery network, you can whitelist it separately with the hash of its certificate.
            <certificate algorithm="SHA-256"
                hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the secure version check applet. -->
        <action permission="run" />

Option 2

System Administrators or Developers can overwrite the application’s signature and add the appropriate Manifest entries. While it does not involve code changes, modifying a JAR file will break the digital signature and requires generating a new one. If you take someone else’s signed document and make changes – your changes invalidate the document they signed, so you need to white-out their signature and apply your own.

There is an existing tutorial for updating JAR files and Modifying a Manifest file. The subset of steps needed for updating to the latest requirements are:

  1. Identify the appropriate JAR file by looking at the JNLP deployment descriptor file. There is a JAR resource specification inside that looks like:
    <jar href="JavaDetection.jar" />
  2. Extract the MANIFEST.MF file:
    jar -xf JavaDetection.jar META-INF/MANIFEST.MF
  3. Open META-INF/MANIFEST.MF in a text editor. Modify the entries that you need, following the Security Manifest Properties documentation:
    1. Permissions – either sandbox or all-permissions. Sandbox is recommended unless the RIA needs further permissions.
      e.g. Permissions: sandbox
    2. Codebase – the original developer often does not have enough information to supply this optional attribute because they do not know where it will be deployed. Provide your hosting location and domain.
      e.g. Codebase:
    3. Caller-Allowable-Codebase – If your RIA requires a calling web page to make LiveConnect calls into the RIA, providing this optional attribute will allow those calls without additional user prompts. The original developer may not have this information because they might not know where it will be deployed. For LiveConnect, this must be provided even if it is the same as the Codebase.
      e.g. Caller-Allowable-Codebase:
  4. Place your MANIFEST.MF file back into the JAR file:
    jar -ufm JavaDetection.jar META-INF\MANIFEST.MF
  5. The final step is to sign the JAR file using your own certificate.
    1. Optional: If you want to verify that these modifications invalidated the previous signature :
      jarsigner -verify JavaDetection.jar
    2. Apply your own signature to the file:
      jarsigner -verbose -keystore "c:\Users\ecostlow \javakeystore_keepsecret.jks" -signedjar JavaDetection.jar -tsa your-certificiate-alias
After updating the MANIFEST.MF file, you can publish the new JAR files for users to access. 

LiveConnect changes in 7u45

Java 7 update 45 (October 2013) introduces a new warning to users of LiveConnect applications. LiveConnect is a technology for Rich Internet Applications that allows JavaScript on a web page to make calls into an RIA, allowing the two to work together and load content. RIAs that do not use LiveConnect are unaffected by this change.

What changed: Users are prompted to confirm a domain when it makes its first LiveConnect call.
How is this different: Previously, LiveConnect calls were allowed by default.

For the first LiveConnect call (per-site), the Java plugin will ask the user if they want to allow interactions from [this domain] to interact with the currently running RIA. This allows the user to confirm known sources (such as the hosting site) and block alternate sources, such as on-page advertising networks or browser plugins. Prompts will displayed when that a web page performs a LiveConnect call. Prompts about LiveConnect cannot be made beforehand because the caller does not exist.

The LiveConnect warning looks like this:
LiveConnect Dialog: Allow access to the following application from this web site?

Developers looking to avoid this warning within their applications may use the optional Caller-Allowable-Codebase attribute within their JAR file’s Manifest.  The Caller-Allowable-Codebase attribute provides a list of domains that can make LiveConnect calls in to the application. This is different than the optional Codebase attribute, which describes the domains from which JAR files may be loaded, although both use similar syntax.


Manifest-Version: 1.0
Created-By: 1.7.0_45
Caller-Allowable-Codebase: *

RIA developers looking to understand which messages will appear as a result of the end-user’s security slider may consult the Rich Internet Deployment Process flowchart. This chart depicts the checks that will be performed on a user’s system, from version-update checks through checking the signature and appropriate Manifest Permissions. The checks are split into two categories: Before your RIA and With your RIA.

Before your RIA:

  1. Is Java registered in the browser?
  2. Does a rule exist on the user’s system to whitelist this RIA? (e.g. a Deployment Rule Set)
  3. Is the user’s Java version at or above the security baseline?

With your RIA:

  1. Does the RIA have a valid code signature?
  2. Does the RIA meet requirements of the user’s security slider?
  3. Are LiveConnect calls from [this domain] allowed?

Thursday Oct 10, 2013

Signing code for the long-haul

With recent code-signature requirements for Rich Internet Applications, I have received a few good questions from different types of developers

  • What is the role of code signing?
  • How do I prevent my signature from expiring? 

What is the role of code signing?

Code signatures allow people who will receive and use your code to determine that you are, in fact, the publisher and that no one else has intentionally or accidentally modified your deliverable. Code signatures protect against these modifications within your supply chain, when moving across a network, or when appearing through 3rd party distribution channels. Code signatures offer a level of repudiation: even though an imposter tries to look like your app, both you and your customers can prove that it isn’t.

There are two concepts for this level of trust:

  1. Identity, the application providing a claim as to who wrote it.
  2. Authentication, the JRE automatically validating this claim against a set of known trust stores.

The way that this information is provided and checked is through industry standard Certificates, which tie together information about the signers (their identity) with the ability to mathematically verify it (through a key).

For a description on why code signatures are taking a more prominent role within the Java Platform, please see our previous entry, Code Signing – Understanding Who and When.

How do I prevent my signature from expiring?

Trusted Timestamping, introduced in Java 5 (2004), allows your customers to validate your signature even after the certificate has expired. When you sign a JAR file, the Timestamp Authority uses their clock to act as a notary and cryptographically write the date and time into your file.

Without this timestamp, users would only be able to validate your signature based on their current date and time. This could be problematic for long-running or embedded systems because the standard X.509 Certificates contain a NotAfter date that typically ranges from one to four years.

You interact with timestamp authorities when signing code with jarsigner’s TSA argument:

jarsigner -tsa …

When your signed file provides a timestamp, Java is able to use that information within the PKIXParameters and determine:

  1. Do I trust this timestamp authority to act as a notary?
  2. Is the signature date before the certificate’s time of expiration?
  3. Based on Certificate Revocation Lists, was this certificate valid on or before the signature date?

If the answer to all questions is yes, then the signature is deemed valid even if the certificate has expired. Therefore, signed code on embedded devices will continue to operate beyond the Certificate’s lifetime.

Certificate revocation may affect the ability to trust a timestamped artifact even if the timestamp occurred before the revocation. Some Certificate Authorities do not currently allow back-dating of revocations, which call to question which happened first: the revocation or the timestamp. Java systems may ignore the timestamp when they identify that the code-signing certificate has been revoked.

Several trusted timestamp authorities are listed in the previous post, “Code signing: Understanding who and when.”

A note about Certificate Authorities and revocation lists

Part of the acceptance criteria for being included in Java’s root certificate authority program is allowing back-dating of certificate revocation in the event that a private key is lost or stolen and continuing to publish revocation information even after a Certificate’s public expiration.

Monday Sep 09, 2013

New security requirements for RIAs in 7u51 (January 2014)

Java 7 update 51 (January, 2014) intends to include two security changes designed to enhance authentication and authorization for Rich Internet Applications (Applets and Web Start). The default security slider is being updated in a way that will block RIAs that do not adhere to these requirements.  Note: this only applies to RIAs, and not to Java on server or desktop applications run outside of a browser.


  • You are required to sign all RIAs (Applets and Web Start applications).
  • You are required to set the "Permissions" attribute within the Manifest.
  • Your application will be affected if it uses Java started through a web browser. Your application will not be affected if it runs anywhere outside of a web browser.

Complete information can be found within the Java 7 update 51 release notes (here once 7u51 is released in January 2014).


 As of 7u51, (January 14, 2014), your RIAs must be updated. The updates required are on the packaging and distribution; no API code changes should be required. The impetus for these changes relates to potential re-purposing of sandboxed applications, whereby placing permissions within a signed JAR prevents modification of your specified permission level.
RIAs must contain two things:

  1. Code signatures from a trusted authority. All code for Applets and Web Start applications must be signed, regardless of its Permissions attributes.
  2. Manifest Attributes
    1. Permissions – Introduced in 7u25, and required as of 7u51. Indicates if the RIA should run within the sandbox or require full-permissions.
    2. Codebase – Introduced in 7u25 and optional/encouraged as of 7u51. Points to the known location of the hosted code (e.g.


Manifest-Version: 1.0
Created-By: 1.7.0_51
Permissions: sandbox

This manifest file is created when the JAR is packaged, either through the default jar command, your build tool, or your IDE.

Sample JNLP for launching a web start application:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="JavaDetection_applet.jnlp">
        <title>Java Detection</title>
        <vendor>Oracle Inc.</vendor>
        <jar href="JavaDetection.jar" />
          name="Java Detection Applet"
     <update check="background"/>

Some developers may notice that the <security /> element is missing from the above JNLP. By providing it within the cryptographically signed JAR file, it is no longer necessary within the JNLP for Java 7 update 51 (January 2014).

See the Development and Deployment Of Rich Internet Applications for full details of JNLPs and the deployment toolkit. For instructions on signing code, see the tutorial Lesson: Signing Code and Granting It Permissions.

Desktop Administrators

If you are a desktop administrator managing Java installations across a series of computers, consider using Deployment Rule Sets to whitelist your internal applications. Deployment Rule Sets allow you to certify that an application is known to be trusted and safe, even if you cannot update the application to adhere to these requirements.

Tuesday Aug 20, 2013

Introducing Deployment Rule Sets

As the Java security model has hardened for browser-based applets, desktop administrators have asked for ways to manage version compatibility and security updates for their end-users.

A new feature is being introduced in Java 7 update 40 called “Deployment Rule Set,” designed to address the issue of security and compatibility in browser applets without affecting normal back-end Java programs like Eclipse, Freemind, or Tomcat. Specifically this deployment rule set addresses two major points:

  1. The desktop administrator’s ability to control Java version compatibility, and default choices on the end-user’s desktop. For example your users may use most recent security updates for most browser applets but still use an old Java 1.6 for that one legacy application that is no longer maintained.
  2. The end-user’s awareness of who created the application and their default interaction (ask, run, or block). By seeing the actual company or signer, the user is protected from running code by someone that they do not know. For example, I would trust “My University” or “Erik Costlow” but not “Unknown publisher” or someone else claiming to be me.

This feature is geared towards two types of users:

Desktop Administrators, who manage a number of users and need to control version compatibility and default dialogs to specific company applets. Desktop Administrators should learn how to control Java across these user systems. For example, “automatically run browser applets signed by our company” or “run all our browser applets with the latest secure version, except for this one internal system that we know needs Java 1.6.”

Developers, who create Java applets and Web Start applications should be aware of the role that deployment rule sets play on their end-user’s desktop.

How to create a deployment rule set

By creating a deployment rule set, desktop administrators can control execution and dialog prompts for desktop users and allow them to run known Java applets, either created by the company or used in critical systems.

Creating a deployment rule set involves a set of steps done once that can then scale out to any number of users and continue working in their future Java updates:

  1. Identify critical applets and web start applications, either by location (e.g., name (e.g. Solitaire), or code-sign hash.
  2. Create a file called ruleset.xml
  3. Package your ruleset.xml into a signed DeploymentRuleSet.jar
  4. Deploy your DeploymentRuleSet.jar to user desktops
  5. Verify usage of your rule set on a client desktop

Identify critical Applets and Web Start applications

Find locations of known applets that your users interact with as part of their normal work. There are many means for gathering this information, from asking/monitoring users to speaking with your director of engineering if their team is creating applets. Ultimately, they can be listed through three means:

  1. Location
    • This is a pattern matcher for URLs. You can identify applets through a simple combination of wildcards and automatic directories.
    • The benefit of location is that it is easy to collect the right information.
    • Examples:
      • *
        This will implicitly cover anything located beneath the panel folder
  2. Certificate Hash
    • If you are following the security practice of signing your code so that users know your applets, you can provide a SHA-256 hash of your public certificate.
    • The benefit of a certificate hash is that it recognizes a publisher, irrespective of location. The downside is that you must find the appropriate certificate.
    • Examples of SHA-256 hashes look like 63 characters of hexadecimal: 794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6
    • To get these hashes, download a signed jar file or obtain one from the developers and run:
      1. keytool -printcert -jarfile MyProgram.jar > cert.txt
      2. Open cert.txt and find the earliest relevant signature. For example, I chose ours:
        Owner: CN="Oracle America, Inc.", OU=Software Engineering, OU=Digital ID Class 3 - Java Object Signing, O="Oracle America, Inc.", L=Redwood Shores, ST=California, C=US
        and then copied the hash line appearing a little later:
        SHA256: 79:4F:53:C7:46:E2:AA:77:D8:4B:84:3B:E9:42:CA:B4:30:9F:25:8F:D9:46:D6:2A:6C:4C:CE:AB:8E:1D:B2:C6
      3. Remove the : separator characters.
  3. Title
    • Look at the JNLP launcher to identify the title of the application.
    • Title must occur only with another attribute, like location or certificate. Title may not be used alone since it exists outside signed jars and deployed locations.

For the time being, just create a list of these.

Create a file called ruleset.xml

Once you have a list of critical applets, the next step is to create a single file called rulset.xml that will look like this:

<!-- Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.
  See -->
<ruleset version="1.0+">
		<id location="" />
		<action permission="run" />
		<id location="" />
		<action permission="run" version="SECURE-1.6" /><!-- For example if an application is known not to work on Java 1.7 -->
		<id location="http://localhost" />
		<action permission="run" />
			<certificate algorithm="SHA-256"
				hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the secure version check applet. -->
		<action permission="run" />
		<id location="http://*">
			<certificate algorithm="SHA-256"
				hash="..." />
		<action permission="default" version="SECURE" />
		<id /><!-- Because this is both blank and shown last, it will be the default policy. -->
		<action permission="block">
			<message>Blocked by corporate. Contact if you need to run this app.</message>
			<message locale="fr">Bloqué par l'entreprise. Contacter si vous avez besoin d'exécuter cette application.</message>

Complete details for creating this file can be found in the Deployment Rule Set documentation, but the gist is to specify the default action of which should run (with no interaction from the user), which should perform the default behavior (prompting the user), and which should be automatically blocked (explaining why).

Package your ruleset.xml into DeploymentRuleSet.jar

Packaging your ruleset allows the desktop administrator to apply cryptographic signatures and prevent users from overriding your policy. This requires usage of a trusted signing certificate. The easiest route to get a signature is to buy one from a certificate authority like Symantec/Verisign, Comodo, GoDaddy, or any other; but in this case I have instructed my JVM to use a custom costlow-ca certificate authority (which only works on my machine). The default certificate authority list contains about 80 authorities from which you may purchase a signing certificate.

C:\Users\ecostlow\DeploymentRuleSet>jar -cvf DeploymentRuleSet.jar ruleset.xml
added manifest
adding: ruleset.xml(in = 1492) (out= 612)(deflated 58%)

C:\Users\ecostlow\DeploymentRuleSet>jarsigner -verbose -keystore "c:\Users\ecostlow \javakeystore_keepsecret.jks" -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar costlow-ca
Enter Passphrase for keystore:
  signing: ruleset.xml

Deploy your DeploymentRuleSet.jar to user desktops

After creating the signed jar, desktop administrators should copy the DeploymentRuleSet.jar to the documented area for their platform so that rules are enforced for all users, across Java updates.

Verify usage of your rule set on a client desktop

For end-users, simply have them visit a website like and verify their Java version (this site uses an applet, so see if it runs).

For desktop administrators, test your Deployment Rule Set by opening the Java Control Panel and navigating to the Security tab:

Clicking the “View the active Deployment Rule Set” should show you your same ruleset.xml file.

End Result

After performing the steps above, desktop administrators can now better control usage of the Java dialogs and prompts for managed users that will function across Java updates. To make changes in the future, simply roll out a new distribution of the DeploymentRuleSet.jar.

Notes and what Deployment Rule Set is not:

The Deployment Rule Set features is intended for mostly enterprise users to manage their own configurations. It is not meant as a way to simply "whitelist everything just so warning dialogs go away," "force everyone to never update," or "external users please download this file onto your system to use this application." By default, specifying the version="SECURE" attribute is best unless you know specific reasons indicating compatibility with a specific JRE version.

Publicly distributed Deployment Rule Sets found to contain insecure "whitelist everything" configurations may have their signing certificate blacklisted from future use of Deployment Rule Sets.


Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.


« October 2015