OpenSSL 1.1.0 - kann ich apache24 und OpenVPN damit bauen?

Status
Für weitere Antworten geschlossen.
Nachtrag:
Verwende ich openssl statt openssl-devel aus den Port gibt es mit openvpn, stunnel und apche24 keine Probleme mit poudriere für das Zielsystem FreeBSD 11 (x86).

Hier die Datei <jailname>-make.conf

Code: 
#DEFAULT_VERSIONS+=ssl=openssl-devel
DEFAULT_VERSIONS+=ssl=openssl

Die Ports und das Jail ist aktuell. Damit ist OpenSSL 1.1.0 für die ALIX-Kiste (noch?) nicht möglich.
 
Nun habe ich auch apache24, openvpn, stunnel für FreeBSD 11 (amd64) mit poudriere gebaut. Die gleichen Probleme in graugrün wie bei i386. Nur stunnel ist möglich.

Ich versuche mal nginx.

Nachtrag:

Code: 
Finished build of www/nginx: Ignored: is marked as broken: does not build with DEFAULT_VERSIONS+=ssl=openssl-devel: undefined reference to SSLeay_version

Das war es dann. Die Hoffnung stirbt zuletzt.
 
security/openssl-devel installiert eben OpenSSL 1.1, was als Hauptversionsrelease eine veränderte API hat. Da müssen erst die Anwendungen hinterherfrickeln. Was erfahrungsgemäß lange bis ewig dauern kann.
 
Ein Teilerfolg:

poudriere baute OpenVPN für FreeBSD 11 (x86) mit openssl-devel

Code: 
Finished build of security/openvpn: Success

Wird chacha20 nun unterstützt von OpenVPN? Keine Ahnung.

Fehlanzeige für apache24 wegen apr.
 
Bin als blutiger Laie in Bezug auf FreeBSD und poudriere über einen falschen Handbucheintrag gestolpert.

Ich wollte das mit poudriere erstellte repo auf der ALIX-Kiste nutzen und habe bei FreeBSD nachgeschlagen.

Dort steht:
Code: 
custom: {
    url: "http://pkg.example.com/10amd64",
    enabled: yes,
}

Das Muster funktionierte nicht. Fand die Lösung im Netz:

Code: 
url: "http://server_domain_or_IP/packages/freebsd_10-1x64-HEAD/",

Mit dieser kleinen aber wichtigen Änderung ("/packages") war ein

pkg upgrade -f

endlich vom "poudriere-repo" möglich.

Was hat es gebracht?
Code: 
/usr/local/bin/openssl ciphers

zeigt mir CHACHA20 an aber
Code: 
/usr/local/sbin/openvpn --show-ciphers

meldet kein CHACHA20.

Das ist das gleiche Verhalten wie auf meinem PC. Dort ist allerdings Linux drauf.
Was sagt mir das? OpenVPN wird wohl nach Arbeit reinstecken müssen oder

sehe ich das wieder mal was falsch? Wer kann mir Tipps geben?
 
Zuletzt bearbeitet:
foxit schrieb:
Bei deiner URL liefert der Webserver das so aus mit dem /packages.
Zum Vergrößern anklicken....

Meine URL habe ich doch gar nicht angegeben. Es sind nur Muster ohne Wert im Beitrag.

Okay, das eine Muster war schon wertvoll für mich. Bin aber wie gesagt ein Laie. Nutze FreeBSD nicht leidenschaftlich sondern nach Bedarf.
 
Das Handbuch kann nicht wissen, wie du deinen Webserver konfigurierst. Also die Pfade musst du schon selbst wissen :-)
 
Keine Tipps zu OpenVPN?

Naja, ist ja noch nicht aller Tage Abend. Ich werde am Ball bleiben und die Entwicklung verfolgen.

Ob libressl was bringt? Warum eigentlich?
 
Zuletzt bearbeitet:
Melde einen Teilerfolg mit poudriere/openssl-devel/apache24:

Sowohl x86 als auch x86_64 bauen nun apr als Voraussetzung für apache24. Leider kann apache24 noch nicht gebaut werden. Ein Fehler wird von clang gemeldet. Habe keine Ahnung davon.
 
Was sagen die Experten zu dieser Aussage?

https://wiki.freebsd.org/LibreSSL/ChaCha20

Ist LibreSSL OpenSSL vorzuziehen? Ich kenne mich da wirklich nicht aus!

Nachtrag:

OPNsense nutzt LibreSLL seit Version 15.7 aber pfSense bleibt bei OpenSSL. Da blicke ich nicht mehr durch zumal TrueOS auch LibreSSL nutzt.:confused:
 
Zuletzt bearbeitet:
Die Sache wird immer undurchsichtiger. Habe poudriere (x86) mit LibreSLL auf apache24, OpenVPN, nginx und stunnel angesetzt.

Nur stunnel will nicht bauen. Alle anderen Ports sind OK.

Schade, stunnel brauche ich zusammen mit OpenVPN für x86 während apache24/nginx nicht so wichtig sind.
 
Das Gleiche in graugrün für poudriere mit x86_64 wie im Beitrag #41.

Dieses Inkonsistenz innerhalb FreeBSD ist bedauerlich. Warum wird OpenSSL 1.0.2 noch "ewig" unterstützt? Warum wird nicht generell LibreSSL verwendet?

Fragen über Fragen, die ich als Laie einfach mal in den Raum stelle.
 
Das hatten wir doch schon: OpenSSL hat nur innerhalb einer Hauptversion eine stabile API, aber nicht zwischen den Hauptversionen. Wenn eine neue Hauptversion kommt, müssen die Entwickler ihre Anwendungen anpassen. Das ist nicht immer einfach, viele Anwendungen nehmen daher solche tiefgreifenden Änderungen auch nur bei größeren Versionssprüngen vor. Dazu kommt, dass die älteren OpenSSL-Versionen ja nicht verschwinden. Es gibt genügend Systeme, die sie noch einsetzen, also muss man mehrere Versionen parallel unterstützen. Da ist man dann ganz schnell bei einer #ifdef-Orgie. LibreSSL ist in seiner API noch einmal etwas instabiler, verlangt dann weitere Codepfade und so weiter. Da es ein Nischenprodukt ist, unterstützen viele Anwendungen es gar nicht oder nur mit niederer Priorität.

Das ist auch FreeBSDs "Problem". STABLE-Zweigen bieten, wie der Name schon sagt, eine stabile API und sogar ABI. Es kann daher keine neue OpenSSL-Hauptversion importiert werden, da die API gebrochen werden würde. Inkonsistent ist da allerdings nichts. Die Ports nutzen in Standardeinstellung die OpenSSL-Version aus dem Basissystem, die Möglichkeit andere Versionen auszuwählen ist eher ein Gimmick für Anwender mit speziellen Anforderungen. Ich und sehr viele andere Portmaintainer sehen es dann auch so, dass ein Port heil ist, wenn Poudriere ihn in Standardeinstellung durchbaut. Alles andere darüber wird maximal nebenbei unterstützt, idealerweise indem interessierte Anwender einen Patch schicken. Denn es ist ja nicht nur OpenSSL. Es sind so viele Schrauben, an denen man drehen kann. Macht man das Fass auf jede denkbare Kombination zu unterstützen, kommt man nie mehr auf einen grünen Zweig. Kurz gesagt, wenn du vom Standard abweichst, hast du auch die Aufgabe es zum Laufen zu bringen.

Mit FreeBSD 12 ist wie auch schon gesagt der Plan OpenSSL im Basissystem privat zu machen. Vielleicht wird man auch ganz auf OpenSSL verzichten und stattdessen eine alternative, schlankere Alternative wie BearSSL nehmen. Die Ports würden dann eine eigene Standardversion definieren und nutzen. Da diese Standardversion nicht Teil der API des Basissystems ist, kann sie unabhängig von dessen Hauptversionen aktualisiert werden. Aber man wird auch da konservativ bleiben. Sprich späte Wechsel auf neue OpenSSL-Hauptversionen. Ob es LibeSSL wird, ist auch sehr fraglich. Denn u.a. die russischen Anwender haben schon deutlich gemacht, dass LibreSSL für sie nicht akzeptabel ist.
 
OpenSSL 1.1.0 gibt es seit knapp einem Jahr.

Code: 
 Major changes between OpenSSL 1.0.2h and OpenSSL 1.1.0 [25 Aug 2016]

    Copyright text was shrunk to a boilerplate that points to the license
    "shared" builds are now the default when possible
    Added support for "pipelining"
    Added the AFALG engine
    New threading API implemented
    Support for ChaCha20 and Poly1305 added to libcrypto and libssl
    Support for extended master secret
    CCM ciphersuites
    Reworked test suite, now based on perl, Test::Harness and Test::More
    *Most* libcrypto and libssl public structures were made opaque, including: BIGNUM and associated types, EC_KEY and EC_KEY_METHOD, DH and DH_METHOD, DSA and DSA_METHOD, RSA and RSA_METHOD, BIO and BIO_METHOD, EVP_MD_CTX, EVP_MD, EVP_CIPHER_CTX, EVP_CIPHER, EVP_PKEY and associated types, HMAC_CTX, X509, X509_CRL, X509_OBJECT, X509_STORE_CTX, X509_STORE, X509_LOOKUP, X509_LOOKUP_METHOD
    libssl internal structures made opaque
    SSLv2 support removed
    Kerberos ciphersuite support removed
    RC4 removed from DEFAULT ciphersuites in libssl
    40 and 56 bit cipher support removed from libssl
    All public header files moved to include/openssl, no more symlinking
    SSL/TLS state machine, version negotiation and record layer rewritten
    EC revision: now operations use new EC_KEY_METHOD.
    Support for OCB mode added to libcrypto
    Support for asynchronous crypto operations added to libcrypto and libssl
    Deprecated interfaces can now be disabled at build time either relative to the latest release via the "no-deprecated" Configure argument, or via the "--api=1.1.0|1.0.0|0.9.8" option.
    Application software can be compiled with -DOPENSSL_API_COMPAT=version to ensure that features deprecated in that version are not exposed.
    Support for RFC6698/RFC7671 DANE TLSA peer authentication
    Change of Configure to use --prefix as the main installation directory location rather than --openssldir. The latter becomes the directory for certs, private key and openssl.cnf exclusively.
    Reworked BIO networking library, with full support for IPv6.
    New "unified" build system
    New security levels
    Support for scrypt algorithm
    Support for X25519
    Extended SSL_CONF support using configuration files
    KDF algorithm support. Implement TLS PRF as a KDF.
    Support for Certificate Transparency
    HKDF support.

Soll diese Arbeit umsonst sein? Nach fast einem Jahr kann ich z. B. chacha20 und Poly1305 nur sporadisch in FreeBSD nutzen. Wie macht es OpenBSD in dieser Beziehung? OpenBSD kenne ich leider gar nicht.

Okay, FreeBSD 11 enthält im Basisystem "OpenSSL irgendwas". Alle Ports bauen damit und es ist Friede, Freude, Eierkuchen. Leider bleiben zur Zeit die von OpenSSL 1.1.0 eingeführten neuen Verschlüsselungsmöglichkeiten (chacha20, Poly1305) in wichtigen Anwendungen (apache24, nginx) auf der Strecke.

Ich will hier keinem die Schuld zuweisen. Wenn aber in einem Jahr die Anwendung YXZ noch meint unbedingt OpenSSL 1.0.2 verwenden zu müssen, dann würde ich ins Grübeln kommen und mich in das Zeitalter der Postkutschen zurücksehnen. Ich könnte mich aber auch zurücklehnen und hoffen, das es schon irgendwie ins Lot kommt.

Anfrage:

Ist LibreSSL wirklich so "exotisch"? Wenn ja, warum wird es von TrueOS genutzt?

Nun, ich habe für heute genug genervt. Werde von poudriere/libressl Abstand nehmen, wieder auf poudriere/openssl-devel zurückgehen und warten.
 
Ich möchte mal als Unbedarfter Gelegenheitsleser meinen Senf dazu abgeben. ich hoffe sehr, dass FreeBSD da noch konservativ bleibt und nicht über-schnell auf einen der schönen neuen Züge aufspringt.
Das gilt ganz generell für mich und nicht speziell bei dem Thema OpenSSL - LibreSSL - irgendwas Anderes-SSL und deren Versionen.
Es gab einen Standpunkt, dass eines der Hauptprobleme mit FreeBSD sei, dass es zu groß ist.
Wenn man sich überlegt, was da alles von wie wenigen Menschen so nebenbei gemacht wird, dann scheint mir das schon vernünftig. Ein kleineres System oder vielleicht nur einen Kernel, den hätte man deutlich einfacher und mit weniger Aufwand zu warten und weiter zu entwickeln.
Nun kommen noch die zahlreichen Drittanbieter-SW hinzu, die allermeist nicht für FreeBSD oder eines der anderen BSDs entwickelt werden. Die Anpassungen ans System sind schon eine endlos große Arbeit und es kann durchaus schocken, wenn die vielen Installationsmeldungen über verwaiste Ports liest.
Die Wahl "eines neuen SSL" ist sehr bedeutend und zieht sich durch extrem viele Abhängigkeiten. Dafür sollte man sich gut Zeit lassen und nicht schnell entscheiden.

TrueOS wird von vielen aus dem FreeBSD-Lager aus mancherlei Gründen nicht mit größtem Wohlwollen betrachtet. Im Grunde wollen die etwas und benutzen dazu FreeBSD und nutzen das für ihren Webauftritt und die zugehörige Werbung aus. Was die wollen, ist nicht identisch mit Zielen von FreeBSD und es nimmt auch nicht gegenseitig aufeinander Bezug. TrueOS hat bestimmte Nutzer im Blickpunkt und erschafft ein Endanwendergerechtes Nischenprodukt. Man ist von der eigenen Idee überzeugt und angetan und setzt um, was man dort für richtig (oder Werbewirksam) hält. Das hat, wie schon gesagt, keinen Bezug zu FreeBSD und dessen Entwicklungen.

OpenBSD ist etwas kleiner und radikaler als FreeBSD. Bei OpenBSD baut man aus Überzeugung schon mal etwas Neues ein, was den Anwender dann vollends verblüfft und schlagartig die Abwärtskompatibilität bricht. FreeBSD ist da viel konservativer und progressiver. Es stößt dem Anwender weniger deutlich vor den Kopf und realisiert Neuerungen meist ziemlich sachte und damit auch langsam. Das ist für mich ein guter Grund, weshalb ich mich bei FreeBSD so viel wohler fühle, als etwa im GNU/Linux Umfeld, wo die hastigen Wechsel und plötzlichen Entscheidungen mich immer besonders trafen, da ich ja als einfacher Endanwender damit nicht mithalten konnte.

Wie oben gesagt, FreeBSD ist schon recht groß und hat relativ wenig Man-Power. Manchmal kommen Dinge deshalb auch wirklich nur quälend langsam, die Alle für total sinnvoll und ausgereift halten. Ich verstehe die Kritik und gleichzeitig, weshalb es bei FreeBSD eben so ist. Für mich ist es gut erträglich und ich mochte die langsame Art schließlich lieber, als die hektischen und manchmal sehr sprunghaften Änderungen bei anderen Systemen. Allermeist sind die langsamen Entscheidungen bei FreeBSD dann auch länger da, man muss seltener etwas wieder um-schmeißen und schnellen Ersatz schaffen.
 
pit234a schrieb:
Die Wahl "eines neuen SSL" ist sehr bedeutend und zieht sich durch extrem viele Abhängigkeiten. Dafür sollte man sich gut Zeit lassen und nicht schnell entscheiden.
Zum Vergrößern anklicken....

Man hat sich mit der Nutzung von OpenSSL 1.1.0 schon zu viel Zeit gelassen bei den FreeBSD-Anwendungen wie apache24, nginx. Das ist meine Meinung, die eines Laien. Ich bitte um Entschuldigung für meine Unkenntnis der unüberwindlichen Schwierigkeiten, die es beim Thema OpenSSL 1.1.0 und FreeBSD zu geben scheint.

Was FreeBSD im Basissystem verwendet ist mir egal wenn ich OpenSSL 1.1.0 aus den Ports benutzen kann. Ich bin gespannt wie die Geschichte ausgeht und ob ich mal vor der Kiste den Erfolg erleben kann.

Werde mal bei Linux reinschauen wie weit die es gebracht haben. Ich nehme an, dass da auch einige Anwendungen rumgezickt haben.

Ein Kenner von OpenBSD hat sich ja nicht zu diesem Thema zu Wort gemeldet und TrueOS Kenner scheint es nicht zu geben.

Nachtrag in Bezug auf Linux und OpenSSL 1.1.0

Ich gehe davon aus, dass der Blogger fefe viel mehr von OpenSSL versteht als ich. Deshalb bringe ich mal eine Bemerkung von ihm hier rein:

"Das mit Chacha20 war bei mir übrigens auch der Auslöser für den Umstieg auf 1.1. OpenSSL 1.1 hat nämlich endlich Support für die Dan-Bernstein-Erfindungen Chacha20 und Poly1305. Je älter ich werde, desto weniger traue ich Krypto-Sachen, die nicht von djb kommen oder von ihm abgenickt wurden. Der Mann hat einfach zu oft Recht behalten, als alle anderen abgewunken, relativiert oder gelacht haben. Ich sehe übrigens keinen inhaltlichen Grund, wieso man Chacha20 und Poly1305 nicht auch in 1.0.2 haben sollte, das gibt es seit Jahren für 1.0x-Versionen von OpenSSL als Patch, und LibreSSL hat es auch von Anfang an drin. Finde ich absolut unverständlich, was das OpenSSL-Team sich da leistet."

Stammt aus

https://blog.fefe.de/?ts=a93f56bb
 
Zuletzt bearbeitet:
Freigeist schrieb:
Man hat sich mit der Nutzung von OpenSSL 1.1.0 schon zu viel Zeit gelassen bei den FreeBSD-Anwendungen wie apache24, nginx.
Zum Vergrößern anklicken....
Und was hat FreeBSD mit dem Apache httpd, mit nginx und so weiter zu tun? FreeBSD nimmt die Anwendungen, wie der Upstream sie bereitstellt und paketiert sie. Wenn der Upstream Unterstützung für OpenSSL 1.1 bietet, tut das FreeBSD-Paket es auch. Tut der Upstream es nicht... Tja, dann geht's halt nicht. Es gibt zwar einige Linux-Distros, die in solchen Fällen die Anwendungen eigenmächtig patchen, aber eigentlich will man das nicht. Denn solche eigenmächtigen Änderungen sind schon viel zu oft böse schief gegangen und werden es sicher auch weiterhin tun.
 
Mir gefällt es auch, dass FreeBSD nicht sofort jeden Trend mitmacht und Änderungen vernünftig und getestet stattfinden. Wenn bei FreeBSD 12 OpenSSL privat ist, wird die SSL-Sache bestimmt besser aussehen. Bis dahin steht es einem frei, entweder selbst eine Lösung zu finden, oder falls es noch keine gibt, zu schauen, dass man eine Lösung schafft. Bei letzterem kann man seine Ergebnisse ja bereitstellen, damit mehrere Leute davon profitieren können. Man könnte auch in entsprechenden Bereichen Themen dazu erstellen, bzw. bereits vorhandene Themen durch einen Beitrag nach oben holen. Ich kann mir vorstellen, dass je frequentierter ein Thema diskutiert wird, desto eher rückt es auch in den Fokus derjenigen, die "auf der anderen Seite" Einfluss nehmen können.

Leider hat die FreeBSD Community nicht so viel Mannstärke wie die Linux Community, weshalb es eigentlich umso besser ist, wenn sich auch Anwender in irgendwelcher Art konstruktiv beteiligen!
 
Wenn ich in meinen Firefox, es werkelt ein Linux System mit OpenSSL 1.1.0, die Netwerkanalyse aufrufe bekomme ich folgende Informationen zur Sicherheit:

- https://blog.fefe.de
Cipher-Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Was sagt uns das? Bereits heute kann CHACHA20 dankt OpenSSL 1.1.0 oder LibreSSL genutzt werden.

Vermutung: der Blogger fefe setzt nicht auf FreeBSD. Nutzt er OpenBSD oder Linux? Ich habe keine Ahnung. Ob fefe OpenSSL oder LibreSSL nutzt kann ich auch nicht sagen.
Alpine Linux soll ja z. B. OpenSSL rausgeworfen haben und LibreSSL nutzen.

Hier mal ein Vergleich:

- https://www.bsdforen.de
Cipher-Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben