Wenn Java hängt, langsam startet, Ports nicht öffnen kann, … dann könnte es mal wieder an random/urandom liegen. Man editiere die java.security (“die” im Sinne von “alle”; sudo find / -name "java.security") wie folgt:
securerandom.source=file:/dev/urandomsecurerandom.strongAlgorithms=NativePRNGNonBlocking:SUNEbenso wieder mal: Danke, Nils!
Disclaimer: Der Post ist 100 Jahre alt, aber wo ich ihn nun gerade in den Entwürfen finde…:
The Legion of the Bouncy Castle bietet mit bc-fips FIPS 140-2-zertifizierte Security Provider an, und zu der umfangreichen Dokumentation gibt es ein paar Good-to-knows:
Security.addProvider(new BouncyCastleFipsProvider()); hinzugefügt werden; per Security.insertProviderAt(new BouncyCastleFipsProvider(), 1) (die Position ist 1-based) gibt es eine RuntimeException: “Could not merge Java truststore with system truststore”EC.generateKeyPair(), die Methode gibt es so nicht. Stattdessen gibt es eine generateKeyPair() unter Beispiel 31 im selben PDF:|
1 2 3 4 5 |
public static KeyPair generateKeyPair() throws GeneralSecurityException { KeyPairGenerator keyPair = KeyPairGenerator.getInstance("EC", "BCFIPS"); keyPair.initialize(384); return keyPair.generateKeyPair(); } |
/dev/random zu sein; ein apt install haveged hilft|
1 2 3 4 5 6 7 8 9 |
// key pair: KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA", "BCFIPS"); generator.initialize(2048); return generator.generateKeyPair(); // content signer: new JcaContentSignerBuilder("SHA256WithRSA") .setProvider("BCFIPS") .build(privateKey); |
keyStore.load(null, null); (Danke, Nils!)HTH
|
1 2 |
cd /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64 sudo keytool -importcert -file '/path/to/my.cer' -keystore lib/security/cacerts -alias "myAlias" -trustcacerts -storepass changeit |
Obacht: Den Alias darf (sollte) man anpassen, aber das Passwort ist tatsächlich “changeit” 🙃
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Add-Type @" using System.Net; using System.Security.Cryptography.X509Certificates; public class TrustAllCertsPolicy : ICertificatePolicy { public bool CheckValidationResult( ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) { return true; } } "@ [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\response.json' |
via. PS, in einem Vagrantfile so zu escapen – man beachte auch die Einrückungen:
|
1 2 3 4 5 6 7 |
config.vm.provision "disable cert validation callback", type: "shell", inline: <<-SHELL Add-Type @" ... "@ [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\\response.json' SHELL |
HTH
Wer irgendwas mit zufällig generierten Token in einem Docker Container laufen lassen möchte, der sollte /dev/urandom auf /dev/random mounten, denn sonst blockiert /dev/random, bis genug Entropie vorhanden ist – die nie kommt. urandom blockiert nicht.
|
1 |
-v /dev/urandom:/dev/random |
Danke, Nils!
In eigener Sache: Alle meine Domains erzwingen jetzt https – weil es geht (und).
🚀❤
Pre-Shared Keys sind mit Spring Boot eine Geschichte voller Missverständnisse. Hier jeweils meine:
In der Theorie scheint die Verwendung von https “überflüssig”, denn wenn ich eh nur vorher als “vertrauenswürdig” zertifizierte Clients zulasse, warum dann noch die Verbindung absichern. Naheliegende Antwort: Austausch von Identitäten über http ist nie gut – ⚠
Also https in den application.properties (/application.yml) der Server-Anwendung einschalten:
|
1 2 3 4 |
server.port=8443 server.ssl.enabled=true server.ssl.client-auth=need server.ssl.protocol=TLS |
Die eigentliche Idee ist jetzt: Jeder Client muss ein “trusted” Zertifikat vorweisen. Diese Zertifikate werden in einem “Trust-Store” abgelegt, den der Server bekommt. Der Client bekommt sein Zertifikat ebenfalls, dort in einem “Key-Store”, um sich auszuweisen. Andersrum analog: Das Serverzertifikat bekommt der Client in einem Trust-Store, um den https-Server zu verifizieren, der Server legt das in seinem Key-Store ab.
Insgesamt sieht die Erstellung so aus:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# Generate server key and self signed server certificate keytool -genkey -alias serverkey -keystore serverkeystore.p12 -keyalg RSA -storetype PKCS12 # Generate client key and self signed client certificate keytool -genkey -alias clientkey -keystore clientkeystore.p12 -keyalg RSA -storetype PKCS12 # Export the server certificate keytool -export -alias serverkey -file servercert.cer -keystore serverkeystore.p12 # Export the client certificate keytool -export -alias clientkey -file clientcert.cer -keystore clientkeystore.p12 # Import the server certificate into client truststore keytool -importcert -file servercert.cer -keystore clienttruststore.p12 -alias servercert # Import the client certificate into server truststore keytool -importcert -file clientcert.cer -keystore servertruststore.p12 -alias clientcert |
Wichtig dabei: Die verwendeten Passwörter (klar), aber auch der verwendete Name, beides brauchen wir unten.
PS, siehe unten und hier ⚠
Die Zertifikate kann man dem Server jetzt über einen TomcatConnector bekannt machen, muss man in Spring Boot aber nicht (⚠; Danke, Nils). Stattdessen genügt Folgendes, ebenfalls in den application.properties:
|
1 2 3 4 5 6 7 8 |
server.ssl.key-store=classpath:certificates/serverkeystore.p12 server.ssl.key-password=123456 server.ssl.key-alias=serverkey server.ssl.key-store-password=123456 server.ssl.key-store-type=pkcs12 server.ssl.trust-store=classpath:certificates/servertruststore.p12 server.ssl.trust-store-password=123456 |
Hier verweise ich auf Key-Stores in der .jar, was seit Tomcat 7.0.66+ funktioniert. ⚠
In der Client-Anwendung sieht das etwas anders aus, zuerst die application.properties:
|
1 2 3 4 5 6 |
# custom keys, might be anything: http.client.ssl.key-store=classpath:certificates/clientkeystore.p12 http.client.ssl.trust-store=classpath:certificates/clienttruststore.p12 # I use the same pw for all key-stores: http.client.ssl.trust-store-password=123456 |
Verwendung dann beispielhaft in einem RestTemplate (org.apache.http.* gibt’s hier)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
import org.apache.http.client.HttpClient; import org.apache.http.conn.ssl.NoopHostnameVerifier; import org.apache.http.conn.ssl.SSLConnectionSocketFactory; import org.apache.http.conn.ssl.TrustSelfSignedStrategy; import org.apache.http.impl.client.HttpClients; import org.apache.http.ssl.SSLContexts; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Value; import org.springframework.core.io.Resource; import org.springframework.http.client.HttpComponentsClientHttpRequestFactory; import org.springframework.web.client.RestTemplate; @Value("${http.client.ssl.key-store}") private Resource keyStore; @Value("${http.client.ssl.trust-store}") private Resource trustStore; @Value("${http.client.ssl.trust-store-password}") private String keyStorePassword; private RestTemplate getRestTemplate() { try { SSLContext sslContext = SSLContexts.custom() .loadKeyMaterial( keyStore.getFile(), // pass twice, for key-store AND certificate: keyStorePassword.toCharArray(), keyStorePassword.toCharArray()) .loadTrustMaterial( trustStore.getURL(), keyStorePassword.toCharArray(), // use this for self-signed certificates only: new TrustSelfSignedStrategy()) .build(); HttpClient httpClient = HttpClients.custom() .setSSLSocketFactory(new SSLConnectionSocketFactory(sslContext, new NoopHostnameVerifier())) .build(); return new RestTemplate(new HttpComponentsClientHttpRequestFactory(httpClient)); } catch (IOException | NoSuchAlgorithmException | KeyStoreException | UnrecoverableKeyException | CertificateException | KeyManagementException e) { throw new RuntimeException(e); } } // ... RestTemplate restTemplate = getRestTemplate(); String url = https://example.com:8443/some/where/{myParam} MyObject myObject = restTemplate.getForObject(url, MyObject.class, Maps.newHashMap("myParam", 42)); |
ACHTUNG: Der NoopHostnameVerifier war hier nötig, da ich das Zertifikat nicht mit expliziten Hostnames erstellt habe, in Production würde man das wohl tun. ⚠
Natürlich kann man mehrere Client-Zertifikate verwenden, und natürlich kann man jedem Client separate Rechte zuweisen. In der Server-Anwendung:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
@EnableWebSecurity @EnableGlobalMethodSecurity(prePostEnabled = true) public class WebSecurityConfig extends WebSecurityConfigurerAdapter { private static final String USER1 = "USER_1"; private static final String USER2 = "USER_2"; // ... @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests().anyRequest().hasAnyAuthority(USER1, USER2) .and().x509() // extracts the user field from the certificate; "CN" is "common name": .subjectPrincipalRegex("CN=(.*?)(?:,|$)") .userDetailsService(userDetailsService()); } @Bean public UserDetailsService userDetailsService() { return username -> { if (username.equals("Name from certificate")) { return new User(username, "", AuthorityUtils.commaSeparatedStringToAuthorityList(USER1)); } // else ... throw new SecurityException("user " + username + " is unknown"); }; } } |
(Quelle und Stack Overflow)
btw: Spring Security bringt einen default User mit (“user”, Passwort wird auf der Konsole beim Hochfahren ausgegeben). Deaktivierung in den application.properties:
|
1 |
security.basic.enabled=false |
hth
Bsplw. so:
|
1 |
$ /usr/lib/jvm/jdk1.8.0_73/bin/ControlPanel |
Wer nicht sicher ist, wo seine Java-Installation liegt:
|
1 |
$ dpkg -L openjdk-8-jre |
listet alle vom JDK installierten Dateien auf.
Es gibt durchaus gute Tutorials und Examples für Spring Boot Security. Nur benutzen die alle Thymeleaf als Templating Engine. Und Thymeleaf hat eine Besonderheit: Wenn man im Form “th:action” statt “action” verwendet, dann wird automatisch ein hidden Input Field mit dem CSRF-Token injected!
Wenn man stattdessen bsplw. Velocity verwendet, und das Template 1:1 übersetzt, merkt man nicht, dass etwas fehlt m( Der Server gibt “403 Forbidden” ohne weitere Fehlermeldung zurück (Tipp zum Debuggen: Der Request wird irgendwann auf die Error-Route umgebogen, aber der Fehler (hier noch inklusive Fehlermeldung) steht im Response-Object).
Offenbar muss man den Token dann manuell dem Template übergeben (Quelle, weicht aber leicht ab):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@RequestMapping(value = "/login") public String login( @RequestParam(value = "error", required = false) String error, @RequestParam(value = "logout", required = false) String logout, HttpServletRequest request, Map<String, Object> model) { CsrfToken csrfToken = (CsrfToken) request.getAttribute(CsrfToken.class .getName()); if (csrfToken != null) { model.put("_csrf",csrfToken.getToken()); } return "pages/login"; } |
|
1 2 3 4 5 6 |
private static final Logger logger = Logger.getLogger(UiController.class); // ... Authentication auth = SecurityContextHolder.getContext().getAuthentication(); logger.debug("User " + auth.getName() + " is here!"); |
Übrigens: Hier wird beschrieben, wie man in Thymeleaf den Token in jeden Ajax-Request bekommt. Leider funktioniert das so nicht, denn um den Platzhalter zu ersetzen, muss man th:content verwenden (Quelle indirekt), sonst wird der Platzhalter nicht ausgewertet m(
|
1 2 |
<meta name="_csrf" th:content="${_csrf.token}" /> <meta name="_csrf_header" th:content="${_csrf.headerName}" /> |
Dann: Siehe hier für das Absetzen der Requests (in jQuery oder Angular)
Auf PHPIDS bin ich in der c’t 10/2009 (S. 164 ff) gestoßen. Es geht um ein PHP-Script, das, in alle öffentlich zugänglichen Scripte einer Webseite eingebunden, Einbruchsversuche erkennen soll. Diese werden dann geratet, und der Webmaster im Zweifelsfalls per Email informiert. Klingt erstmal gut, vor allem aus folgenden Gründen:
Das Dumme an diesem Plugin: So lange es aktiviert ist, geht der Bilder-Upload nicht mehr, Fehlermeldung (sinngemäß aus dem Gedächtnis): “Are you sure you want to do this? Try again”; der angebotene Link führt dann aber aus dem Backend auf den eigentlichen Blog. So viel dazu.
PS: WordPress Version 2.7.1, WPIDS 0.1.2