Https / Security Question

Question

I made an applet which connects to an https server. I want to ensure that a rogue applet cannot call the servlet the same way my real applet can. If a rogue applet could get in, I would have to write additional code to perform login authentication before executing the remainder of the servlet.
I was wondering if the login authentication is necessary or not because maybe the HttpsURLConnection is satisfactory enough to prevent unauthenticated calls???
I have the following code demonstration below.
APPLET
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLSession;
import javax.net.ssl.HostnameVerifier;
import java.net.URL;
import java.net.HttpURLConnection;
import java.io.ObjectOutputStream;
import java.io.ObjectInputStream;
import java.util.TreeMap;
import java.util.Iterator;
public class AppletTest {
   public final static void main( String[] args ) {
      try {
         final Object[] oArr = new Object[]{"paramForServletA", "paramForServletB"};
   //    final URL url = new URL( "http://localhost/servletPath/MyServlet" );
   //    final HttpURLConnection servletConnection = ( HttpURLConnection ) url.openConnection();
         final URL url = new URL( "https://mySite.com/servletPath/MyServlet" );
         final HttpsURLConnection servletConnection = ( HttpsURLConnection ) url.openConnection();
         servletConnection.setHostnameVerifier(
            new HostnameVerifier() {
               public boolean verify( final String urlHost, final SSLSession ssls ) {
                 return true;
         servletConnection.setDoInput( true );
         servletConnection.setDoOutput( true );
         servletConnection.setUseCaches( false );
         servletConnection.setDefaultUseCaches( false );
         servletConnection.setRequestProperty( "Content-type", "application/octet-stream" );
         // Read the object to the servlet
         final ObjectOutputStream outputToServlet = new ObjectOutputStream( servletConnection.getOutputStream() );
         outputToServlet.writeObject( oArr );
         outputToServlet.flush();
         outputToServlet.close();
         // Read the input from the servlet.
         final ObjectInputStream inputFromServlet = new ObjectInputStream( servletConnection.getInputStream() );
         final Object result = inputFromServlet.readObject();
         inputFromServlet.close();
         System.out.println( "Data: " +(String)result );
      catch ( Exception e ) {
         System.out.println( "Could not establish Connection : " + e.toString() );
}SERVLET
public final class MyServlet extends HttpServlet {
   public void doPost( HttpServletRequest request, HttpServletResponse response ){
     ObjectInputStream inputFromApplet = new ObjectInputStream( request.getInputStream() );
     Object[] args = ( Object[] ) inputFromApplet.readObject();
     //etc...
     ObjectOutputStream outputToApplet = new ObjectOutputStream( response.getOutputStream() );
     outputToApplet.writeObject( data );
     outputToApplet.flush();
     outputToApplet.close();
}If I call this with a HttpURLConnection I can see the data returned, which is bad since I may be a rogue applet. If I call it with an HttpsURLConnection I get the following message:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate foundIs the HttpsUrlConnection good enough, or should additional measures be taken?

Answer 1

Authentication via HTTPS might involve putting a
certificate on the client where your applet is
running.Are you saying a signed applet? Or is this a
completely different thing?Completely different thing. When you install SSL on your server, you get a certificate from Verisign or somebody else in the trust business, and the idea is that the certificate verifies to your client, via SSL, that your server is really your server and not some other pirate box pretending to be your server.
Likewise you could install a certificate on your client. That certificate would then verify to you that your client was really your client and not some other pirate box. Client certificates aren't used much, because it's a hassle to create them and get them installed on your client, but they do exist.