Hi everyone,

I believe I understand where the issue loading OpenSSL's
legacy provider comes from (for MD4 support) and I am currently working on a fix here:
https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0-providers

Basically the OpenSSL provider module for legacy algorithms is not built correctly, since the switch to OpenSSL 3.0.9 in base. The same goes with the FIPS module, where finding an elegant solution is more difficult than for the legacy one, but I'm getting there.

Anyway, I will keep updating this branch until it's ready for a pull-up request, very likely with force-pushes in order to polish the commits before submission.

Let me know how it goes!

Cheers,
-- Pierre

On 6/29/23 23:56, Dustin Marquess wrote:
On Jun 29, 2023 at 11:36 AM -0500, FreeBSD User <free...@walstatt-de.de>, wrote:

    Am Thu, 29 Jun 2023 16:41:51 +0200
    Guido Falsi <m...@madpilot.net> schrieb:

        On 29/06/23 16:35, FreeBSD User wrote:

            Hello,

            running a recent CURRENT, 14.0-CURRENT #10
            main-n263871-fd774e065c5d: Thu Jun 29 05:26:55
            CEST 2023 amd64, xfreerdp (net/freerdp) doesn't working
            anymore on Windows 10 guest in
            bhyve. It seems OpenSSL 3 is the culprit (see the error
            message from xfreerdp below). I
            opened already a PR (see:
            https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272281). In a
            very quick response I was informed that recent FreeRDP
            doesn't support OpenSSL 3 yes
            (https://github.com/FreeRDP/FreeRDP/pull/8920).

            Checking for HowTo's setting up bhyve guests, I dodn't
            realise any setting for
            alternatives to RDP. As I do not fully understand how bhyve
            passes through its guest's
            framebuffer device/ or native GUI, I'm a bit helpless in
            searching for another solution to
            contact the Windows10 guest from the X11 desktop of the hosts.

            Trying remmina turns out to be a fail, because in our
            installation libsoup2 and libsoup3
            are installed both and remmina complains about having both
            symbols, also I realised
            remmina seems to utilize net/freerdb as the RDP backend.

            Since I have no clue how to install "blindly" a VNCserver
            within the Windows10 guest, I
            presume VNC is not an option in any way.

            Is there any way to access the bhyve guest's native
            graphical interface? As in the PR shown
            above already documented (setup taken from the FreeBSD
            Wiki/bhyve), a framebuffer is
            already configured.

            It would be nice if someone could give a hint.


        I had the same issue, with Windows 10 pro hosts, but the fault is in
        windows, which, by default, tries to negotiate an ancient
        protocol (NTLM
        using RC4 if I understand correctly).

        With modern windows RDP servers there are better protocols
        available,
        you can get them in remmina by forcing "TLS protocolo security"
        in the
        advanced tab, security protocol negotiation (second row).

        Doing this (after some experimentation with various options)
        solved the
        issue for me.


    Thank you very much for the quick response.

    net/remmina is not an option on most of my workstations, since some
    required ports install
    libsoup3, and remmina complains about having found libsoup2 symbols
    as well as libsoup3
    symbols when starting up - and quits.

    Since remmina utilises net/freerdp, I was wondering if I could
    enforce TLS security by any
    kind of a switch, and trying the following

    xfreerdp /v:192.168.0.128:5900 /u:ohartmann /sec:tls

    resulting in

    [...]
    [17:58:18:972] [1702:bb812700] [WARN][com.winpr.utils.ssl] - OpenSSL
    LEGACY provider failed to
    load, no md4 support available!
    [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] -
    BIO_read returned an
    error: error:12800067:DSO support routines::could not load the
    shared library
    [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] -
    BIO_read returned an
    error: error:12800067:DSO support routines::could not load the
    shared library
    [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] -
    BIO_read returned an
    error: error:07880025:common libcrypto routines::reason(524325)
    [17:58:18:973]
    [1702:bb812700] [ERROR][com.freerdp.core] -
    transport_read_layer:freerdp_set_last_error_ex
    ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
    [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core.transport] -
    BIO_read returned a
    system error 35: Resource temporarily unavailable
    [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core] -
    transport_read_layer:freerdp_set_last_error_ex
    ERRCONNECT_CONNECT_TRANSPORT_FAILED
    [0x0002000D] [17:58:18:981] [1702:bb812700]
    [ERROR][com.freerdp.core] - freerdp_post_connect
    failed


    My setup is

    bhyve -c 4 -m 4G -w -H \
    -s 0,hostbridge \
    -s 3,ahci-hd,/pool/home/ohartmann/bhyve/win10/disk_win10.img \
    -s 5,virtio-net,tap0 \
    -s 29,fbuf,tcp=0.0.0.0:5900,w=1920,h=1200,vga=io \
    -s 30,xhci,tablet \
    -s 31,lpc \
    -l com1,stdio \
    -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
    win10

    and this is a working image setup a couple of weeks ago when VBox
    has been defective on
    CURRENT - should say: it worked once.

    I can not interpret the error above.

    bhyve is novel to me and I have to admit that I make some capital
    mistakes here - but can't
    find satisfying doucumentation ...

    Kind reagrds,

    Oliver


RDP would be on the guest's IP using port 3389.  Port 5900 on the host's IP is bhyve's VNC port, which speaks VNC, not RDP.

If you want to use VNC, try TigerVNC.

-Dustin

--
Pierre Pronchery


Reply via email to