Re: [ipxe-devel] HTTPS & iPXE

[Michael Brown]

On 14/01/2020 22:17, Michael Brown wrote:
This "iPXE root CA" certificate is used to cross-sign every root 
certificate trusted by Mozilla, and a mechanism exists to allow iPXE to 
automatically download these cross-signed certificates as needed.  There 
is a reasonable explanation of this at


   https://ipxe.org/cfg/crosscert

This cross-signed certificate chain includes OCSP checks; this is the 
part that is currently failing.


The OCSP server should now be functional again.  I have given up hope of 
finding time to properly package the OpenCA ocspd for Fedora, and I gave 
up hope almost immediately upon reading the documentation for the 
alternative Dogtag PKI OCSP server.


The solution now in place uses the extremely out-of-date OpenCA ocspd 
present in Fedora, running a separate daemon for each CA, with a quick 
and dirty WSGI script used to dispatch requests to the appropriate backend.


Please let us know if your OCSP problems are now fixed.

Thanks,

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] HTTPS & iPXE

[Michael Brown]

On 14/01/2020 19:54, Ibrahim Tachijian wrote:

The issues you are experiencing are most likely because the iPXE OCSP
service is still down following a hardware death.  Replacement is
currently stalled pending the existence of a suitable ocspd package for
Fedora; the version in the Fedora repos is more than ten years out
of date.

How does this work exactly?
I mean, if my https certificate is based on letsencrypt, then am I still 
dependant on some service (ocsp?) from ipxe to function ?


Can I work around this and still "trust what Mozilla trusts" ?


The root problem is that the Mozilla root certificate list is far too 
large (150kB) to embed within the iPXE binary.


The way that iPXE works around this is to instead embed the 32-byte 
SHA-256 fingerprint of a single "iPXE root CA" certificate (which is the 
certificate that can be downloaded from https://ca.ipxe.org/ca.crt).


This "iPXE root CA" certificate is used to cross-sign every root 
certificate trusted by Mozilla, and a mechanism exists to allow iPXE to 
automatically download these cross-signed certificates as needed.  There 
is a reasonable explanation of this at


  https://ipxe.org/cfg/crosscert

This cross-signed certificate chain includes OCSP checks; this is the 
part that is currently failing.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] successful wpa handshake (memcmp polarity) (#103)

[Joshua Oreman]

I haven't contributed to iPXE in many years, so I don't have write access to 
the Github repo, but this PR looks good to me.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/103#issuecomment-574368989___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] successful wpa handshake (memcmp polarity) (#103)

[Joshua Oreman]

I wrote the original WPA code in 2009, and definitely successfully booted with 
it at that time. It looks like the incorrect-polarity memcmp() was only 
introduced in 2014: 
https://github.com/ipxe/ipxe/commit/8ee39f7432e63c2382ab3e7d24e234310f4532c9

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/103#issuecomment-574368260___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

[ipxe-devel] [ipxe/ipxe] successful wpa handshake (memcmp polarity) (#103)

[Bazz]

Fix memcmp() to return proper standard positive/negative
values for unequal comparisons. Similar to commit 3946aa9. The 
current implementation is backwards (i.e. the functions are returning
negative when they should be positive and vice-versa).

Currently all other consumers of these functions only check the return value
for ==0 or !=0 and so we can safely change the implementation without
breaking things.

However, there is one call that checks the polarity of
`memcmp()`, and that is 
[wpa_derive_ptk()](https://github.com/ipxe/ipxe/blob/8f1514a00450119b04b08642c55aa674bdf5a4ef/src/net/80211/wpa.c#L290-L305)
 during the wireless WPA 4-way
handshake. Due to the incorrect memcmp polarity, the WPA handshake
creates an incorrect PTK, and the handshake would fail after step 2.
Undoubtedly, the AP noticed the supplicant failed the mic check. This
commit fixes that issue.

Signed-off-by: Michael Bazzinotti 

P.S. This wpa handshake bug is believed to have been longstanding for several 
years, and based on my current understanding, it possibly dates back to the 
release of the ipxe wpa feature itself. That makes no sense, but let's look 
at what I have uncovered. It seems a user encountered the exact same issue in 
[iPXE forums in 2016](https://forum.ipxe.org/showthread.php?tid=7943): a mic 
check failure. I realize net booting wirelessly is not popular nor well 
supported, and in that way bugs can live for a long time without being 
addressed. HOWEVER!

`wpa_derive_ptk()` would never run successfully unless with a different 
`memcmp()` function, due to the reversed polarity. How could a single person 
have ever successfully joined a WPA network using ipxe's `memcmp()`? I 
assume the code was ran successfully in the past, right? In those cases, was 
some other `memcmp()` somehow being used? For example, could the system's 
native memcmp() accidently have been superceding ipxe's?

 In any case, it seems a properly built ipxe that uses its internal `memcmp` 
could never generate a correct wpa ptk using `wpa_derive_ptk()` ? If you have 
any additional information to explain why, please by all means. Or join me in a 
state of wonder. Thanks
You can view, comment on, or merge this pull request online at:

  https://github.com/ipxe/ipxe/pull/103

-- Commit Summary --

  * [libc] Fix memcmp() to return proper values
  * [wpa] fix erroneous dbg printout in wpa_derive_ptk

-- File Changes --

M src/core/string.c (2)
M src/net/80211/wpa.c (9)

-- Patch Links --

https://github.com/ipxe/ipxe/pull/103.patch
https://github.com/ipxe/ipxe/pull/103.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/103
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] QRcode (#102)

[dgtlrift]

@dgtlrift pushed 1 commit.

f700041cff22570dacf753a6c72c0261c55d3d82  Update actions to include submodule 
checkout


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/ipxe/ipxe/pull/102/files/9b127eee31d7377e3a89e891ca202ce98003f260..f700041cff22570dacf753a6c72c0261c55d3d82
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] QRcode (#102)

[dgtlrift]

@dgtlrift pushed 2 commits.

f73e062a16dcd83224b035f1a5b13ffe1a148612  Add diagnostics to build log
9b127eee31d7377e3a89e891ca202ce98003f260  Add way too much detail


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/ipxe/ipxe/pull/102/files/cf594e3d4050e36a84c44649053f170e3790131a..9b127eee31d7377e3a89e891ca202ce98003f260
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] HTTPS & iPXE

[Ibrahim Tachijian]

>
> The issues you are experiencing are most likely because the iPXE OCSP
> service is still down following a hardware death.  Replacement is
> currently stalled pending the existence of a suitable ocspd package for
> Fedora; the version in the Fedora repos is more than ten years out of date.


How does this work exactly?
I mean, if my https certificate is based on letsencrypt, then am I still
dependant on some service (ocsp?) from ipxe to function ?

Can I work around this and still "trust what Mozilla trusts" ?

On Sun, Jan 12, 2020, 15:14 Michael Brown  wrote:

> On 11/01/2020 15:28, Ibrahim Tachijian wrote:
> > And all fail because of certificate issues.
> > The documentation on https://ipxe.org/crypto mentions that,
> >
> > In the default configuration, iPXE trusts only a single root
> > certificate: the "iPXE root CA" certificate
> > . This root certificate is
> > used to cross-sign the standard Mozilla list of public CA
> > certificates
> > <
> http://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/ckfw/builtins/certdata.txt
> >.
> >
> > Do  I need to download the iPXE root ca and compile it in? If so how?
>
> No; the iPXE root CA fingerprint is compiled in by default:
>
>https://github.com/ipxe/ipxe/blob/master/src/crypto/rootcert.c#L51
>
> The issues you are experiencing are most likely because the iPXE OCSP
> service is still down following a hardware death.  Replacement is
> currently stalled pending the existence of a suitable ocspd package for
> Fedora; the version in the Fedora repos is more than ten years out of date.
>
> Michael
>
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] QRcode (#102)

[dgtlrift]

@dgtlrift pushed 1 commit.

cf594e3d4050e36a84c44649053f170e3790131a  Add missing file that should have 
been included


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/ipxe/ipxe/pull/102/files/ce783dc3b060c449d3dfd51e3f6cc2723896c3cc..cf594e3d4050e36a84c44649053f170e3790131a
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel