Moderator (MDR): MDR-GregVoss

Guest-Speaker (SPK): SPK-Benjamin and SPK-Marianne

MDR-GregVoss: Hello everyone. Welcome to the Java Security Forum. Joining us today are Marianne Mueller and Benjamin Renaud. Both Marianne and Benjamin are members of the JavaSoft Security team.

Marianne received her CS from the University of Washington in 1987 where she developed a colaborative editor called "CoEdit." She joined Sun in December 1988 where she worked with the floating point group and later on tools for multithreaded programming. She joined the JavaSoft Security team in October, 1995.

Benjamin joined the JavaSoft Security team in July, 1995. He is responsible for Java Security APIs as they relate to cryptography, key management, and related areas such as signed code. Benjamin graduated from MIT in 1994!

Also joining us is Hemma Prafullchandra, who joined the Java security team just a month ago from the Sun Internet Commerce Group. Hemma is working on key management, certificate management, and infrastructure for Certificate Authorities. Hemma graduated from University College London in 1990.

We're ready to field some questions now, so go ahead and send any that you have.

TonyWang: Can you tell what security enhancements are going to be in JDK 1.1?

SPK-Benjamin: For JDK 1.1 we introduce the java.security package. In 1.1, it will include support for Digital Signatures, Message Digests and key management. We will provide implementations of DSA, MD5 and SHA. For key and cert management we offer support for X.509 and PKCS8 key formats, We also provide a persistent database for keys and certificates. The main application of the security API is for signed code support, where developers may sign their code so that end users who receive it, may let the signed code run without security restrictions. Also included in 1.1 are some other miscellaneous useful things: DER parsing classes and ACL interfaces. The signed code support takes advantage of a new archival format, called JAR, which lets you package up applets and the supporting data (images, sounds etc) into one file and send it accross using only one connection! (much better performance...)

TonyWang: I read yesterday about a tumbling Duke applet that would read my password file while showing me animations! Is there any way to prevent bad applets like this? How would it get out of the "sandbox"?

SPK-Marianne: I just started looking into this one yesterday, so I don't have all the details at my fingertips right now. But on the face of it, it isn't a Java bug per se, but someone is using a Java applet to exploit a network weakness. Anyway I am looking at it now, and plan to update the Security FAQ later today with a description of the attack and an analysis of the problem. Like I said, it's not really a Java bug, but since someone is using a Java applet, it's perceived to be a Java bug. P.S. The URL for the Security FAQ is http://java.sun.com/sfaq/.

tone: I've got a general question about the Security Manager. Is JavaSoft or the browser environment responsbile for determining the security policy?

SPK-Marianne: The security policy in the browsers that shipped in 1996 were set by the implementation of the Java-level security manager. That is, the policy is defined, implemented and enforced by the security manager, which is a Java class that is part of the Java platform embodied in a browser like Netscape Navigator or Microsoft's IE. This means that yes, the policy is determined by the browser and is relatively inflexible. The policy that is part of the Applet Execution environment (aka sandbox) is set by JavaSoft and is part of the Java Compatibility requirements. Now, going forward, we recognize the need for a more flexible security architecture that allows both developers and endusers to establish policies that fit their intranet or their own application. So that's the direction we're moving in.

TonyWang: With signed code, will I be able to have access to other APIs?

SPK-Benjamin: It depends on what you mean by access other API... When you use the JDK, and build Java applications, you are able to use all APIs in the JDK. As an applet, you're restricted by security restrictions on a number of APIs (for reading files, for example) These restrictions can indeed be removed using the signed code support.

TonyWang: Will signing code be good just for identifying the creator or will I get extra access if I sign?

SPK-Benjamin: Both really, though the extra rights you get (writing to disk, accessing the network) will depend upon what priviledges the clients grant you. In other words: the client uses signatures to identify the creator and then, based on that information, decides what extra access the code gets.

SPK-Marianne: OK... probably many of you have read this already, but I wanted to point out that we have an interesting dialog about "what security means" and where JavaSoft is going, on the Web site. We put out a statement about what we thought the security challenges are on the Internet, and invited comments from distinguished experts in the field. Their comments were certainly no holds barred! It makes for interesting reading and I think it gives a good perspective on how we see security as being a fundamental system-wide issue—not just a question of layering features on top of a system that isn't particularly architected for secure Internet programming. We got lots of comments about this Web page, and I'm way overdue in getting those comments up on the Web site. But check back soon since "round 2", where the comments will be posted, should be up within the week. Also check out the URL: http://java.sun.com/security— that is the main placeholder for info about Java security, and we'll be updating that area and adding to it from time to time.

MDR-GregVoss: That's helpful. I'm sure people are looking foward to those updates. Now they have a starting point to look for more information in the mean time.

It seems that sockets and firewall pose challenges for a lot of Java programmers.

tone: Could you briefly explain the reason why a socket connection is.

SPK-Benjamin: The basic reason has to do with the fact that it is not desirable to have potentially hostile code initiate network connections to random hosts on the internet from your machine! The canonical example is the hostile applet sending mail to president @whitehouse.gov from your machine, which is not something that should be allowed. It is possible for applets to access documents anywhere on the net using the showDocument method. This won't let the applet get access to the content, but it will show the document to the user.

JohnEng: Are there any implications of using signed classes with firewalls? For the firewall behind which I am, for example, SSL is not allowed. Will there be similar issues with signed class files?

SPK-Benjamin: If you can get applets at all, you will be able to get signed applets. SSL requires a special port, which many firewalls do not support. Applets, including signed applets, use regular HTTP (port 80) and if you can get applets, you can get signed applets!

MDR-GregVoss: Marianne has a few things to add to Benjamin's comments:

SPK-Marianne: What Benjamin said is 100% right—I just wanted to add that we know there is a lot of interest in the firewall community to add features to their products, to selectively filter applets. Right now there are some firewalls that are simply slamming the door shut on applets. People can configure firewalls to do this, and the firewall vendors are providing that kind of switch. So what we are doing, is talking with and working with various firewall vendors, to encourage them to add more flexible capabilities to their firewalls, so that they can let through (say) only signed applets that are signed by some entity that is on a list of trusted signatures. There are naturally a lot of technical issues involved with this, since you immediately get into the whole PKI (public key infrastructure) questions and issues. Namely, how do people publish and retrieve keys, and how do administrators establish those lists of trusted signatures. We are aware of these hard questions and are working on some tools that will be available in followon releases to JDK 1.1.

tone: For years, people have downloaded software that connects to various servers all the time, so why not, for example, put the burdern of security on those implementating the firewall policy rather than Java?

SPK-Marianne: I think what we want to do is enable both sets of end users: adminstrators, and eventual users of browsers. I think that with the Internet, you're in a situation where people control and administer computers although they wouldn't describe themselves or their primary function as being a sysadmin. So it's tricky—we want to make this easy enough to use so that non-sysadmins can configure the system and use it without too much agony, but we also want to enable sophisticated security configurations that are required by corporations and that are administered by fulltime network sysadmins and people in charge of firewalls.

SPK-Benjamin: This goes back to an earlier question, which hinted at the fact that
security is essentially something dependent on the environment, and as Marianne points out, what users are involved.

We're trying to cater both to people who are able to FTP software and look at the source code before running it, and to people who are more naive and not as sophisticated (the usual example is anyone's grandmother...)

BillBryant: Before any major release of JDK (like the upcoming 1.1) how do you ensure that there are no major security holes? Do you have any formal rigorous checking? Do your licensees and others like the Princeton guys get a chance to evaluate it?

SPK-Marianne: That's a great question. As a matter of fact we are working closely with a number of external early access customers who are evaluating and using the JDK 1.1 kit, and giving us feedback. We have been funding the Princeton Internet Security Lab since early this year, and we're in the process of getting the JDK 1.1 to them to ask them for their helpful analysis. I should add that although it's often portrayed in the press as antagonistic, our relationship with people who find bugs and tell us about them is actually very good—we are pleased and delighted that they take the time and put so much energy and dedication into helping us improve Java security.

But to answer your question specifically, there are a number of things we've done this year to help us get a better handle on sandbox security. We funded an outside effort to write down a more rigrous specification of the Java sandbox model. The end result of this is a specification; the "Java Security Model," which is a high level abstract model that lays out the components of the security model, the transitions among components, the invariants that are expected to hold for each transition, and the assumptions that underly some of the states in the model. Well that's all very nice and academic, but we did this not as an academic effort, but to help us structure and build better test suites so that we can do a better job of verifying our implementation of the sandbox. That work is coming to fruition since we are now developing tests that will be added to the Compatibility Kit, as Security Compatibility tests.

MDR-GregVoss: I know a number of people are interested in RSA and government control of encrypted applications:

tone: Is RSA encryption used in JDK 1.1 and if so how will it affect export of Java applications (aren't there U.S. restrications)?

SPK-Benjamin: JDK 1.1 itself does not have any direct interfaces to encryption. Rather it has interfaces to Digital Signature, which are exportable. Soon after 1.1 we will be releasing the rest of the java.security API, which will include encryption interfaces.

As far as implementation goes, we use DSA, which is both free (RSA is not) and specific to digital signatures.

SPK-Marianne: Just to add a quick note—any application that uses anything in the JDK 1.1 in not subject to any export restrictions.

MikeP: The "Black Widow" article caused quite a stir in the community. Do you take explicit steps to prevent such kinds of misconceptions? Do you regularly monitor the c.l.j.security newsgroups?

SPK-Marianne: We do regularly monitor the newsgroups but you know, most people also send email when they find a bug. The "Black Widow" article would have been funny if it hadn't turned into so much confusion. There is no such thing as a "Black Widow" virus written in Java—that article used the melodramatic title or metaphor of Java applets stalking the Web as if they were evil black widows spiders. I guess they were trying to pick up on the web metaphor. Well that simple headline turned into an urban myth that there was some sort of "Black Widow" virus! I talk about this and the other security flare ups on the security FAQ, which you can find at http://java.sun.com/sfaq. So we have to go to a meeting (lunch time meeting!) but keep those cards and letters coming.

SPK-Benjamin: Yes indeed, we always appreciate all feedback from users! Let us know what you think of JDK1.1...

MDR-GregVoss: Well, we're out of time. Thanks everyone for joining us. Hope everyone has a good Thanksgiving holiday. See you next time.