web-dev-qa-db-fra.com

Évitez le blocage du niveau de sécurité sans ajouter d'URL dans la liste des sites d'exception

J'ai créé Java signed applet, il fonctionne parfaitement si je définis mon niveau de sécurité Java (JRE 8) hautet ajoute mon URL du site dans liste de sites d'exception.

Mais si nous n’ajoutons pas l’URL du site dans la liste des sites d’exception, l’exception de sécurité Java vient comme expliqué ici: ajouter l’URL dans la liste des sites d’exception

J'ai créé une applet signée à l'aide d'un certificat de troisième partie.

Voici mon fichier manifeste après avoir créé un applet signé:

Existe-t-il une option disponible pour éviter ces fenêtres contextuelles bloquant la sécurité en ajoutant des modifications au fichier manifeste lors de la création d'une applet signée, ou tout script, code Java permettant d'éviter ces fenêtres contextuelles sans ajouter d'URL de site dans la liste des sites d'exception?

Ou bien est-ce vraiment obligatoire à partir de Java que nous devons ajouter l'URL du site dans la liste des sites d'exception pour éviter une telle erreur de blocage.

Existe-t-il une option disponible pour ajouter notre URL dans la liste des sites d’exception via un fichier manifeste ou un code Java? Blocking popup comes if we don't set url in exception list

Est-il obligatoire si je veux signer mon applet à l'aide d'un certificat signé, alors il doit s'agir d'un certificat de signature de code? le certificat de wildcard ou de ssl ne fonctionnera pas?

Comme je suis auto-signée problème de blocage d'applet bien que j'ai signé mon applet avec un certificat générique.

javasecurityappletsigned-applet
5
Java

Votre application est considérée comme auto-signée parce que vous l'avez signée avec un certificat qui n'est pas destiné à la signature de code. Les applications auto-signées sont bloquées avec ce pop-up séduisant:

Vous pouvez empêcher cette fenêtre contextuelle si vous vous connectez à l'aide d'un certificat de signature de code signé par une autorité de certification approuvée. Ensuite, l'utilisateur obtiendra une boîte de dialogue de confirmation plus agréable, qui répertorie votre nom en tant qu'éditeur de l'application:

Reportez-vous également à la documentation d'Oracle sur les dialogues sécurité pour obtenir une description des dialogues et indiquer pourquoi et quand ils apparaissent.

Consultez la documentation sur l'utilisation des RIA signées , en particulier 23.2 "Signature des RIA", pour savoir comment créer un certificat de signature de code pour signer votre applet.

Un deuxième lien Nice est http://www.Oracle.com/technetwork/Java/javase/tech/Java-code-signing-1915323.html#5

--METTRE À JOUR--

Qu'est-ce qui fait qu'un certificat est un certificat de signature de code?

Les certificats X.509 peuvent inclure des champs d'utilisation de clé (KU) et des champs d'utilisation de clé étendue (EKU). Ces champs, lorsqu'ils sont présents, restreindre l'utilisation valide du certificat. Le plugin Java vérifie la présence de ces champs.

J'ai trouvé le code source du EndEntityChecker qui effectue cette vérification.

/**
 * Check whether this certificate can be used for code signing.
 * @throws CertificateException if not.
 */
private void checkCodeSigning(X509Certificate cert)
        throws CertificateException {
    Set<String> exts = getCriticalExtensions(cert);

    if (checkKeyUsage(cert, KU_SIGNATURE) == false) {
        throw new ValidatorException
           ("KeyUsage does not allow digital signatures",
            ValidatorException.T_EE_EXTENSIONS, cert);
    }

    if (checkEKU(cert, exts, OID_EKU_CODE_SIGNING) == false) {
        throw new ValidatorException
            ("Extended key usage does not permit use for code signing",
            ValidatorException.T_EE_EXTENSIONS, cert);
    }

    [...]

    checkRemainingExtensions(exts);
}

Les méthodes de vérification se présentent comme suit:

/**
 * Utility method checking if the extended key usage extension in
 * certificate cert allows use for expectedEKU.
 */
private boolean checkEKU(X509Certificate cert, Set<String> exts,
        String expectedEKU) throws CertificateException {
    List<String> eku = cert.getExtendedKeyUsage();
    if (eku == null) {
        return true;
    }
    return eku.contains(expectedEKU) || eku.contains(OID_EKU_ANY_USAGE);
}

Notez que si aucun KU ou EKU n'est spécifié, le vérificateur KU ou EKU renvoie true. Mais si les KU sont spécifiées, la signature numérique KU devrait en faire partie. De même, si des unités EKU sont spécifiées, EKU signature du code (identifié par l'identifiant d'identification 1.3.6.1.5.5.7.3.3) ou l'EKU toute utilisation _ (identifié par l'identifiant d'identification 2.5. 29.37.0) devraient également être spécifiés.

Enfin, la méthode checkRemainingExtensions réprimande quand elle rencontre d’autres EKU critiques pertinentes.

Je suppose donc que votre certificat SSL générique spécifie au moins un EKU qui n'est pas signature du code} _ et n'est donc pas reconnu comme un certificat de signature du code valide par le plug-in Java.

3
flup

Ou bien est-il vraiment obligatoire de Java que nous devions ajouter l'URL du site dans la liste des sites d'exception pour éviter une telle erreur de blocage.

Fondamentalement oui. Les utilisateurs finaux peuvent désactiver la fenêtre contextuelle sécurisée, mais vous ne pouvez pas le faire via votre application. Si vous consultez la documentation Oracle "Eviter les dialogues de sécurité" . Il est clairement indiqué que le popup de sécurité est un comportement attendu:

Java Runtime avertira automatiquement l'utilisateur des éventuels problèmes de sécurité. Si vous êtes sûr que les applications que vous utilisez sont sûres, vous pouvez contourner les boîtes de dialogue de sécurité pour simplifier l'expérience de l'utilisateur. Si une application applet/webstart Java est signée, une boîte de dialogue d'avertissement sur la sécurité des certificats s'affiche. L'utilisateur doit cliquer sur le bouton Exécuter pour donner toutes les autorisations au code de l'application.

Et si vous lisez les options pour éviter le popup, vous verrez qu'elles impliquent toutes de modifier quelque chose sur l'ordinateur de l'utilisateur final.

Voici les options (citées dans "Éviter les dialogues de sécurité" ):

  • L'utilisateur accepte le certificat utilisé pour signer l'application et coche la case Toujours faire confiance au contenu de cet éditeur. La prochaine fois, des autorisations seront automatiquement accordées à cette application (jusqu'à ce que le certificat expire ou soit supprimé du magasin de clés de confiance).

  • Le certificat peut être importé manuellement dans le magasin de certificats de confiance JRE. Pour importer le certificat à l'aide du panneau de configuration Java, sélectionnez l'onglet Sécurité, puis sélectionnez Certificats> Certificats approuvés. Pour importer un certificat dans le magasin de certificats à partir de la ligne de commande, utilisez l'utilitaire keytool (situé dans le dossier bin du JRE).

  • Accordez AllPermissions dans le fichier de règles Java situé sous $ {user.home} /. Java.policy ou pointez sur un fichier de règles Java dont AllPermissions se trouve dans le fichier $ (JRE_HOME) /lib/security/Java.security. Les autorisations peuvent être accordées à toutes les applications ou limitées à une URL particulière. Voir Implémentation de stratégie par défaut et Syntaxe du fichier de stratégie pour plus de détails sur .Java.policy.

1
alain.janinm

Essayez de modifier le manifeste en ajoutant le nom de votre serveur dans callbase-code-base. Vous n'avez probablement plus besoin d'ajouter l'URL de votre site dans une exception

METTRE &AGRAVE; JOUR:

Voici un exemple de mon fichier manisfest:

Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Application-Name: myApp
Name: MyName
Permissions: all-permissions
Created-By: 1.7.0_51 (Oracle Corporation)
Caller-Allowable-Codebase: MyServerName
Codebase: *
0
Andrea Baglioni